6.17. GCC-6.2.0

6.17.1. Installation de GCC

La documentation de GCC recommande de construire GCC dans un répertoire de construction dédié :

mkdir -v build
cd       build

Préparez la compilation de GCC :

SED=sed                               \
../configure --prefix=/usr            \
             --enable-languages=c,c++ \
             --disable-multilib       \
             --disable-bootstrap      \
             --with-system-zlib

Remarquez que pour d'autres langages, il existe des prérequis pas encore disponibles. Voir le livre BLFS pour des instructions sur la manière de construire tous les langages supportés par GCC.

Compilez le paquet :

make

Un ensemble de tests dans la suite de tests de GCC est connu pour déborder la pile, donc augmentez la taille de la pile avant de lancer les tests :

ulimit -s 32768

Testez les résultats mais ne vous arrêtez pas aux erreurs :

make -k check

Pour recevoir un résumé des résultats de la suite de tests, lancez 

../contrib/test_summary

Pour n'avoir que les résumés, redirigez la sortie vers grep -A7 Summ.

Vous pouvez comparer les résultats avec ceux situés dans http://www.linuxfromscratch.org/lfs/build-logs/7.10/ et http://gcc.gnu.org/ml/gcc-testresults/.

Quelques échecs inattendus sont inévitables. Les développeurs de GCC connaissent ces problèmes, mais ne les ont pas encore résolus. En particulier, deux tests dans la suite de tests de libstdc++ sont connus pour échouer quand ils sont éxécutés avec l'utilisateur root comme nous le faisons ici. Sauf si les résultats des tests sont très différents de ceux sur l'adresse ci-dessus, vous pouvez continuer en toute sécurité.

Installez le paquet :

make install

Créez un lien symbolique requi par le FHS pour des raisons « historiques ».

ln -sv ../usr/bin/cpp /lib

Beaucoup de paquets utilisent le nom cc pour appeler le compilateur C. Pour satisfaire ces paquets, créez un lien symbolique :

ln -sv gcc /usr/bin/cc

Ajoutez un lien symbolique de compatibilité pour permettre la construction de programmes avec Link Time Optimization (LTO):

install -v -dm755 /usr/lib/bfd-plugins
ln -sfv ../../libexec/gcc/$(gcc -dumpmachine)/6.2.0/liblto_plugin.so \
        /usr/lib/bfd-plugins/

Maintenant que notre chaîne d'outils est en place, il est important de s'assurer à nouveau que la compilation et l'édition de liens fonctionneront comme prévu. Cela se fait en effectuant les mêmes tests de propreté que ceux faits plus haut dans ce chapitre :

echo 'int main(){}' > dummy.c
cc dummy.c -v -Wl,--verbose &> dummy.log
readelf -l a.out | grep ': /lib'

Il ne devrait pas y avoir d'erreur et la sortie de la commande sera (avec des différences spécifiques aux plateformes dans le nom de l'éditeur de liens) :

[Requesting program interpreter: /lib/ld-linux.so.2]

Maintenant, assurez-vous que nous utilisons les bons fichiers de démarrage :

grep -o '/usr/lib.*/crt[1in].*succeeded' dummy.log

La sortie de la dernière commande sera :

/usr/lib/gcc/i686-pc-linux-gnu/6.2.0/../../../crt1.o succeeded
/usr/lib/gcc/i686-pc-linux-gnu/6.2.0/../../../crti.o succeeded
/usr/lib/gcc/i686-pc-linux-gnu/6.2.0/../../../crtn.o succeeded

Selon l'architecture de votre machine, le message ci-dessus peut légèrement différer, la différence portant normalement sur le nom du répertoire après /usr/lib/gcc. Si votre machine est un système 64 bits, il se peut que vous voyiez un répertoire nommé lib64 vers la fin de la chaîne. La chose importante à chercher est que gcc ait trouvé les trois crt*.o sous le répertoire /usr/lib.

Vérifiez que le compilateur cherche les bons fichiers d'en-têtes :

grep -B4 '^ /usr/include' dummy.log

Cette commande devrait afficher la sortie suivante :

#include <...> search starts here:
 /usr/lib/gcc/i686-pc-linux-gnu/6.2.0/include
 /usr/local/include
 /usr/lib/gcc/i686-pc-linux-gnu/6.2.0/include-fixed
 /usr/include

A nouveau, notez que le nom du répertoire après votre triplette cible peut être différent de celui ci-dessus, selon votre architecture.

Puis, vérifiez que le nouvel éditeur de liens est utilisé avec les bons chemins de recherche :

grep 'SEARCH.*/usr/lib' dummy.log |sed 's|; |\n|g'

Les références vers des localisations qui ont des composants avec '-linux-gnu' doivent être ignorées, sinon la sortie de la dernière commande doit être :

SEARCH_DIR("/usr/i686-pc-linux-gnu/lib32")
SEARCH_DIR("/usr/local/lib32")
SEARCH_DIR("/lib32")
SEARCH_DIR("/usr/lib32")
SEARCH_DIR("/usr/i686-pc-linux-gnu/lib")
SEARCH_DIR("/usr/local/lib")
SEARCH_DIR("/lib")
SEARCH_DIR("/usr/lib");

Il se peut qu'un système 64 bits voie d'autres répertoires. Par exemple, voici la sortie d'une machine x86_64 :

SEARCH_DIR("/usr/x86_64-unknown-linux-gnu/lib64")
SEARCH_DIR("/usr/local/lib64")
SEARCH_DIR("/lib64")
SEARCH_DIR("/usr/lib64")
SEARCH_DIR("/usr/x86_64-unknown-linux-gnu/lib")
SEARCH_DIR("/usr/local/lib")
SEARCH_DIR("/lib")
SEARCH_DIR("/usr/lib");

Ensuite, assurez-vous que nous utilisons la bonne libc :

grep "/lib.*/libc.so.6 " dummy.log

La sortie de la dernière commande devrait être (avec un répertoire lib64 sur les hôtes 64 bits) :

attempt to open /lib/libc.so.6 succeeded

Pour finir, assurez-vous que GCC utilise le bon éditeur de liens dynamiques :

grep found dummy.log

La sortie de la commande devrait être (avec des différences spécifiques aux plateformes dans le nom de l'éditeur de liens et un répertoire lib64 sur les hôtes 64 bits) :

found ld-linux.so.2 at /lib/ld-linux.so.2

Si la sortie n'apparaît pas comme montré ci-dessus ou qu'elle n'apparaît pas du tout, alors quelque chose ne va vraiment pas. Enquêtez et retracez les étapes pour savoir d'où vient le problème et comment le corriger. La raison la plus probable est que quelque chose s'est mal passé lors de la modification du fichier specs ci-dessus. Tout problème devra être résolu avant de continuer le processus.

Une fois que tout fonctionne correctement, nettoyez les fichiers tests :

rm -v dummy.c a.out dummy.log

Enfin, déplacez un fichier mal placé :

mkdir -pv /usr/share/gdb/auto-load/usr/lib
mv -v /usr/lib/*gdb.py /usr/share/gdb/auto-load/usr/lib