2017-06-07 3 views
0

étapes de base menant à la question:GCC 4.9.4 compilateur croisé Construire (numéro limits.h)

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 ../ 

Le problème que je suis en cours d'exécution en est que ce qui finit par s'installer dans $ {prefix} /lib/gcc/${TARGET}/4.9.4/include-fixed/limits.h ne semble pas être correct. Plus précisément, le bit "fixincludes" dans la construction et l'installation de GCC attend un répertoire appelé "sys-include" qui n'a jamais été mis en place et quand ce n'est pas le cas, limits.h ne fait pas référence au syslimits.h associé (dans le même répertoire).

Si je regarde dans la sortie de la séquence de construction/installation, il y a une référence à la construction de ce fichier à partir des composants limitx.h, limity.h et d'autres bits. Ce test échoue et il installe juste le "generic" limits.h fourni avec GCC (qui n'inclut pas une référence à syslimits.h qui utilise la directive #include_next de GCC pour inclure $ {PREFIX}/$ {TARGET}/include/limits.h qui a réelle choses dans ce que j'ai besoin comme NAME_MAX et PATH_MAX).

Le bit qui manque à partir du fichier est:

/* 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 

Donc, il y a une option que je ne suis pas passer au script de configuration de GCC ou que je ne suis pas de passer à quelque chose avant cette étape qui créerait le répertoire sys-include correctement?

[EDIT]

TARGET=i686-redhat-linux (un triple objectif de "-dumpmachine gcc" sur un serveur de build que nous utilisons pour le projet)

informations Peut-être plus utile (?): Les paquets étaient tout simplement « wget "tire des archives respectives. Je suis basé sur une installation Ubuntu 16.04 mise à jour où j'ai installé libgmp-dev et libmpfr-dev pour éviter d'avoir à les compiler avec le code source du compilateur.

+0

Quelle est la valeur de $ {TARGET} '? Veuillez modifier la question pour l'améliorer. –

+0

Mise à jour de la question avec quelques informations supplémentaires. J'espère que cela pourra aider! –

Répondre

0

Après plus de creuser et d'essayer-et-erreur, j'ai fait correspondre certaines choses que j'ai commencé avec How to Build a GCC Cross-Compiler avec des informations sur une option apparemment obsolète --with-headers pour la configuration de GCC. (--with-headers=${PREFIX}/${TARGET}/include/linux) Cela a fonctionné mais quand j'ai construit la bibliothèque de support de compilateur il s'est plaint de manquer bits/stdio_lim.h. J'ai trouvé un autre article here qui parle de ce problème (vous devez remonter dans le fil un peu) et avait mentionné la chose touchante gnu/stubs.h de la première page que j'ai mentionnée.

Ajouté à mon propre commentaire ci-dessous de noter que vous devez supprimer le répertoire ${PREFIX}/${TARGET}/sys-include qui obtient construire après l'étape make install-gcc ou bien vos têtes normales C vont entrer en conflit avec les en-têtes spécifiques du noyau Linux qui sont inclus dans la recherche chemin par défaut.

Qu'il suffise de dire que, après l'application d'un patch à l'ancienne Glibc j'utilisais (2.11.3) toute séquence se termine à quelque chose comme ceci:

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 ../ 

Je ne vois pas de pages en fait aller à cette profondeur (peut-être que la page Preshing on Programming n'est pas totalement correcte?) mais je vais tester cette configuration et m'assurer que le logiciel se construit complètement pour la cible sans problèmes. (J'ai testé NAME_MAX from limits.h dans un fichier et il a semblé fonctionner très bien et dandy.)

Je ne sais pas vraiment que je dois mettre dans la chose --disable-multilib mais cela semble être ce que d'autres les pages sont en train de faire.Cette chaîne dans la liste de diffusion GCC parle d'utiliser --with-newlib ou --disable-shared en tant qu'options, mais les personnes sur le thread ne pouvaient pas être d'accord que ce soit la bonne solution.

Si quelqu'un a un meilleur aperçu de cela, j'apprécierais certainement une solution moins hacky, plus officielle au problème.

Au cas où quelqu'un se demandait, le patch (il y a deux) pour fixer glibc 2.11.3 est une solution personnalisée pour le script de configuration pour fonctionner avec GNU Make 4+:

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

... et un correctif réel à deux fichiers dans la bibliothèque pour fixer i686 suport:

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__ 

j'ai eu cette dernière pièce de here.

+0

Cela ne semble pas non plus suffisant. Le problème est que GCC inclura une série d'en-têtes de noyau Linux dans le répertoire sys-include et l'heure du noyau Linux.h est en conflit avec time.h de GCC/Glibc et vous obtenez une redéfinition de (au moins) 'struct timeval'. Donc, n'ont pas encore entièrement résolu le problème. –

+0

Donc, après avoir lutté avec cela pendant un moment, j'ai simplement fini par supprimer le répertoire '$ {PREFIX}/$ {TARGET}/sys-include' et maintenant tout semble compiler. (Au moins aussi loin que j'ai testé.) Je vais modifier cela et mettre à jour comme une réponse si cela fonctionne correctement. –