6.21. GCC-8.2.0

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

Temps de construction approximatif: 92 SBU (avec les tests)
Espace disque requis: 3.9 Go

6.21.1. Installation de GCC

Si vous construisez sur x86_64, changez le nom du répertoire par défaut des bibliothèques 64 bit en « lib » :

case $(uname -m) in
  x86_64)
    sed -e '/m64=/s/lib64/lib/' \
        -i.orig gcc/config/i386/t-linux64
  ;;
esac

Supprimez le lien symbolique créé précédemment car les en-têtes du gcc final seront installés là :

rm -f /usr/lib/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      \
             --disable-libmpx         \
             --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 des nouvelles options de configure :

SED=sed

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

--disable-libmpx

Ce paramètre dit à GCC de ne pas construire mpx (Memory Protection Extensions) qui peuvent poser des problèmes sur certains processeurs. Mpx a été enlevé des versions suivantes de gcc.

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

Supprimez un test connu pour causer un problème :

rm ../gcc/testsuite/g++.dg/pr83239.C

Testez les résultats en tant qu'utilisateur non privilégié, mais ne vous arrêtez pas aux erreurs :

chown -Rv nobody . 
su nobody -s /bin/bash -c "PATH=$PATH 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/8.4/ et https://gcc.gnu.org/ml/gcc-testresults/.

Quelques échecs inattendus sont parfois inévitables. Les développeurs de GCC connaissent généralement ces problèmes, mais ne les ont pas encore résolus. 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

Certaines combinaisons de configuration du noyau et de processeurs AMD peuvent avoir plus de 1100 échecs dans les tests gcc.target/i386/mpx (qui sont conçus pour tester l'option MPX des processeurs Intel récents). Ils peuvent être ignorés sans problème sur les processeurs AMD. Ces tests échoueront aussi sur des processeurs Intel si le support de MPX n'est pas activé dans le noyau même s'il est présent dans le processeur.

Installez le paquet :

make install

Créez un lien symbolique requis 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)/8.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: /lib64/ld-linux-x86-64.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/x86_64-pc-linux-gnu/8.2.0/../../../../lib/crt1.o succeeded
/usr/lib/gcc/x86_64-pc-linux-gnu/8.2.0/../../../../lib/crti.o succeeded
/usr/lib/gcc/x86_64-pc-linux-gnu/8.2.0/../../../../lib/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. 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/x86_64-pc-linux-gnu/8.2.0/include
 /usr/local/include
 /usr/lib/gcc/x86_64-pc-linux-gnu/8.2.0/include-fixed
 /usr/include

À 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/x86_64-pc-linux-gnu/lib64")
SEARCH_DIR("/usr/local/lib64")
SEARCH_DIR("/lib64")
SEARCH_DIR("/usr/lib64")
SEARCH_DIR("/usr/x86_64-pc-linux-gnu/lib")
SEARCH_DIR("/usr/local/lib")
SEARCH_DIR("/lib")
SEARCH_DIR("/usr/lib");

Il se peut qu'un système 32 bits voie différemment quelques répertoires. Par exemple, voici la sortie d'une machine i686 :

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");

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

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

La sortie de la dernière commande sera :

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 dernière commande devrait être (avec des différences spécifiques aux plateformes dans le nom de l'éditeur de liens) :

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

Si la sortie n'apparaît pas comme montrée 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. 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.21.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-8.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