Linux From Scratch - Version 7.10

Chapitre 6. Installer les logiciels du système de base

6.17. GCC-6.2.0

Le paquet GCC contient la collection de compilateurs GNU, qui inclut les compilateurs C et C++.

Temps de construction approximatif: 79 SBU (avec les tests)
Espace disque requis: 3.3 Go

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.

Voici la signification de la nouvelle option de configure :

SED=sed

Configurer cette variable d'environnement empêche un codage en dur du chemin vers /tools/bin/sed.

--with-system-zlib

Ce paramètre dit à GCC de se lier à la copie installée sur le système de la bibliothèque Zlib, plutôt qu'à sa propre copie interne.

Compilez le paquet : 

make
[Important]

Important

Dans cette section, la suite de tests pour GCC est considérée comme critique. Ne les sautez sous aucun prétexte.

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

[Note]

Note

Sur certains systèmes, de nombreux échecs aux tests (plus de 1100 échec non attendus sur plus de 200 000 tests) ont été rapportés. Ces erreurs dans gcc.target/i386/mpx/ sont liés aux tests Intel MPX (Memory Protection Extensions) et les échecs sont dus à la configuration du noyau ou à l'architecture spécifique du CPU. Ces échecs sont sans conséquence et peuvent être ignorés.

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.

[Note]

Note

Depuis la version 4.3.0, GCC installe maintenant sans condition le fichier limits.h dans un répertoire à part include-fixed, et ce répertoire doit être en place.

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

6.17.2. Contenu de GCC

Programmes installés: c++, cc (lien vers gcc), cpp, g++, gcc, gcc-ar, gcc-nm, gcc-ranlib et gcov
Bibliothèques installées: libasan.{a,so}, libatomic.{a,so}, libgcc.a, libgcc_eh.a, libgcc_s.so, libgcov.a, libgomp.{a,so}, libiberty.a, libitm.{a,so}, liblto_plugin.so, libquadmath.{a,so}, libssp.{a,so}, libssp_nonshared.a, libstdc++.{a,so}, libsupc++.a, et libtsan.{a,so}
Répertoires installés: /usr/include/c++, /usr/lib/gcc, /usr/libexec/gcc et /usr/share/gcc-6.2.0

Descriptions courtes

c++

Le compilateur C++

cc

Le compilateur C

cpp

Le préprocesseur C ; il est utilisé par le compilateur pour l'extension des instructions #include, #define et d'autres instructions similaires dans les fichiers sources

g++

Le compilateur C++

gcc

Le compilateur C

gcc-ar

Une enveloppe autour de ar qui ajoute un greffon à la ligne de commande. Ce programme n'est utilisé que pour ajouter "l'optimisation du temps d'édition des liens" et il n'est pas utile avec les options de construction par défaut.

gcc-nm

Une enveloppe autour de nm qui ajoute un greffon à la ligne de commande. Ce programme n'est utilisé que pour ajouter "l'optimisation du temps d'édition des liens" et il n'est pas utile avec les options de construction par défaut.

gcc-ranlib

Une enveloppe autour de ranlib qui ajoute un greffon à la ligne de commande. Ce programme n'est utilisé que pour ajouter "l'optimisation du temps d'édition des liens" et il n'est pas utile avec les options de construction par défaut.

gcov

Un outil de tests ; il est utilisé pour analyser les programmes et savoir où des optimisations seraient suivies du plus d'effet

libasan

La bibliothèque Address Sanitizer à l'exécution

libgcc

Contient un support en exécution pour gcc

libgcov

Cette bibliothèque est liée à un programme où on demande à GCC d'activer le profiling

libgomp

Implémentation GNU de l'API OpenMP API pour la programmation en mémoire parallèle partagée pour plusieurs plateformes en C/C++ et Fortran

libiberty

Contient des routines utilisées par différents programmes GNU comme getopt, obstack, strerror, strtol, et strtoul

liblto_plugin

Greffon GCC's Link Time Optimization (LTO, optimisation du temps d'édition de liens de GCC) permettant à GCC de pratiquer des optimisations tout au cours des unités de compilation.

libquadmath

API de la bibliothèque de maths GCC de précision au carré

libssp

Contient des routines supportant la fonctionnalité de protection de GCCcontre les débordements de mémoire

libstdc++

La bibliothèque C++ standard

libsupc++

Fournit des routines de support pour le langage de programmation C++

libtsan

La bibliothèque Thread Sanitizer à l'exécution