GCC 4.9.4 Cross-Compiler bauen (limits.h Ausgabe)

Question

Grundlegende Schritte auf die Frage im Vorfeld:

cd linux-2.6.35.9/ 
make ARCH=x86 INSTALL_HDR_PATH=${PREFIX}/${TARGET} headers_install 
cd ../ 

cd build-binutils/ 
sh ../binutils-2.28/configure --prefix=${PREFIX} --target=${TARGET} 
make 
make install 
cd ../ 

cd build-gcc/ 
sh ../gcc-4.9.4/configure --prefix=${PREFIX} --target=${TARGET} --enable-languages=c,c++ --disable-multilib 
make all-gcc 
make install-gcc 
cd ../ 

Das Problem, das bei mir läuft in ist das, was landet in $ installiert zu werden {PREFIX} /lib/gcc/${TARGET}/4.9.4/include-fixed/limits.h scheint nicht korrekt zu sein. Insbesondere erwartet das "fixincludes" -Bit beim Erstellen und Installieren von GCC ein Verzeichnis namens "sys-include", das nie eingefügt wurde, und wenn dies nicht der Fall ist, verweist das oben erwähnte limits.h nicht auf die zugehörige syslimits.h (in der dasselbe Verzeichnis).

Wenn ich in die Ausgabe der Build/install-Sequenz schaue, gibt es eine Referenz zum Erstellen dieser Datei aus den Komponenten limitx.h, limity.h und einigen anderen Bits. Dieser Test schlägt fehl und es werden nur die "generischen" limits.h installiert, die mit GCC geliefert wurden (ohne einen Verweis auf syslimits.h, der die # include_next-Direktive von GCC verwendet, um $ {PREFIX}/$ {TARGET} aufzunehmen/include/limits.h das hat tatsächlichen Zeug drin ich brauche wie NAME_MAX und PATH_MAX).

Das Bit, das aus der Datei fehlt, ist:

/* This administrivia gets added to the beginning of limits.h 
    if the system has its own version of limits.h. */ 

/* We use _GCC_LIMITS_H_ because we want this not to match 
    any macros that the system's limits.h uses for its own purposes. */ 
#ifndef _GCC_LIMITS_H_ /* Terminated in limity.h. */ 
#define _GCC_LIMITS_H_ 

#ifndef _LIBC_LIMITS_H_ 
/* Use "..." so that we find syslimits.h only in this same directory. */ 
#include "syslimits.h" 
#endif 

So gibt es eine Option, ich bin nicht auf GCC Konfigurationsskript geben oder dass ich nicht zu etwas vorbei diesem Schritt bin voraus, dass schaffen würde das sys-include Verzeichnis richtig?

[EDIT]

TARGET=i686-redhat-linux (ein Ziel triple von "gcc dumpmachine" auf einem Build-Server wir für das Projekt verwenden)

Möglicherweise weitere hilfreiche Informationen (?): Die Pakete einfach wget“waren "zieht aus jeweiligen Archiven. Ich baue auf einer aktuellen Ubuntu 16.04 Installation auf, bei der ich libgmp-dev und libmpfr-dev installiert habe, um zu vermeiden, dass sie mit dem Quellcode des Compilers kompiliert werden müssen.

Answer 1

Nach mehr Graben und Versuch-und-Irrtum habe ich einige Sachen zusammengebracht, die ich mit How to Build a GCC Cross-Compiler mit Informationen über eine offenbar veraltete Option --with-headers für die Konfiguration von GCC begann. (--with-headers=${PREFIX}/${TARGET}/include/linux) Das funktionierte, aber wenn ich die Compiler-Support-Bibliothek baute, beklagte es sich über fehlende bits/stdio_lim.h. Ich habe einen anderen Beitrag gefunden here, der über dieses Problem spricht (Sie müssen im Thread ein wenig nach oben gehen) und hatte das berührende gnu/stubs.h Ding von der ersten Seite erwähnt, die ich erwähnte.

Hinzugefügt von meinem eigenen Kommentar zu beachten, dass Sie das Verzeichnis ${PREFIX}/${TARGET}/sys-include entfernen müssen, das nach dem make install-gcc-Schritt erstellt wird, da sonst die normalen C-Header Konflikte mit den Linux-Kernel-spezifischen Headern verursachen, die in die Suche einbezogen werden Pfad standardmäßig.

es genügt zu sagen, dass nach einem Patch auf die ältere Glibc Anwendung war ich mit (2.11.3) endet die gesamte Sequenz in etwa so hoch:

export TARGET=i686-redhat-linux 
export PREFIX=$(pwd)/output 
export PATH=${PATH}:${PREFIX}/bin 

mkdir build-binutils 
mkdir build-gcc 
mkdir build-glibc 

cd linux-2.6.35.9/ 
make ARCH=x86 INSTALL_HDR_PATH=${PREFIX}/${TARGET} headers_install 
cd ../ 

cd build-binutils/ 
sh ../binutils-2.28/configure --prefix=${PREFIX} --target=${TARGET} 
make 
make install 
cd ../ 

cd build-gcc/ 
sh ../gcc-4.9.4/configure --prefix=${PREFIX} --target=${TARGET} --enable-languages=c,c++ --disable-multilib --with-headers=${PREFIX}/${TARGET}/include/linux 
make all-gcc 
make install-gcc 
cd ../ 
rm --recursive --force ${PREFIX}/${TARGET}/sys-include 

cd build-glibc/ 
sh ../glibc-2.11.3/configure --prefix=${PREFIX}/${TARGET} --build=$(gcc -dumpmachine) --host=${TARGET} --target=${TARGET} --disable-multilib libc_cv_forced_unwind=yes libc_cv_c_cleanup=yes 
make install-bootstrap-headers=yes install-headers 
make csu/subdir_lib 
install csu/crt1.o csu/crti.o csu/crtn.o ${PREFIX}/${TARGET}/lib 
${TARGET}-gcc -nostdlib -nostartfiles -shared -x c /dev/null -o ${PREFIX}/${TARGET}/lib/libc.so 
touch ${PREFIX}/${TARGET}/include/gnu/stubs.h ${PREFIX}/${TARGET}/include/bits/stdio_lim.h 
cd ../ 

cd build-gcc/ 
make all-target-libgcc 
make install-target-libgcc 
cd ../ 

cd build-glibc/ 
make 
make install 
cd ../ 

Ich sehe keine Seiten, dass tatsächlich zu dieser Tiefe gehen (vielleicht ist die Preshing auf der Programmierseite nicht wirklich völlig korrekt?), aber ich werde diese Konfiguration testen und sicherstellen, dass die Software vollständig für das Ziel ohne Probleme baut. (Ich habe NAME_MAX von limits.h in einer Datei getestet und es schien einfach gut und dandy zu funktionieren.)

Ich weiß auch nicht wirklich, dass ich die --disable-multilib Sache einfügen muss, aber das scheint was anderes zu sein Seiten tun.Diese Kette in der GCC-Mailingliste spricht davon, --with-newlib oder --disable-shared als Optionen zu verwenden, aber die Leute auf dem Thread konnten sich nicht einigen, dass dies die richtige Lösung war.

Wenn jemand einen besseren Einblick in das hat, würde ich sicher eine weniger hacky, offizielle Lösung für das Problem zu schätzen wissen.

Falls jemand fragen, wurde das Patch (es gibt zwei) Glibc 2.11.3 wurde eine individuelle Lösung für das Konfigurationsskript zu beheben mit GNU arbeitet Make 4+:

sed -i 's/\(3.79\)/4.* | \1/' glibc-2.11.3/configure 

... und i686 suport eine aktuelle Patch auf zwei Dateien in der Bibliothek zu beheben:

patch glibc-2.11.3/nptl/sysdeps/pthread/pt-initfini.c <<__EOF__ 
@@ -45,6 +45,11 @@ 
/* Embed an #include to pull in the alignment and .end directives. */ 
asm ("\n#include \"defs.h\""); 

+asm ("\n#if defined __i686 && defined __ASSEMBLER__"); 
+asm ("\n#undef __i686"); 
+asm ("\n#define __i686 __i686"); 
+asm ("\n#endif"); 
+ 
/* The initial common code ends here. */ 
asm ("\n/*@HEADER_ENDS*/"); 

__EOF__ 
patch glibc-2.11.3/sysdeps/unix/sysv/linux/i386/sysdep.h <<__EOF__ 
@@ -29,6 +29,10 @@ 
#include <dl-sysdep.h> 
#include <tls.h> 

+#if defined __i686 && defined __ASSEMBLER__ 
+#undef __i686 
+#define __i686 __i686 
+#endif 

/* For Linux we can use the system call table in the header file 
     /usr/include/asm/unistd.h 
__EOF__ 

ich habe das letzte Patch von here.