8.26.1. Installation de GCC
Tout d'abord, corrigez un problème cassant libasan.a lors de la construction de ce paquet
avec Glibc-2.34 :
sed -e '/static.*SIGSTKSZ/d' \
-e 's/return kAltStackSize/return SIGSTKSZ * 4/' \
-i libsanitizer/sanitizer_common/sanitizer_posix_libcdep.cpp
Si vous construisez sur x86_64, changez le nom du répertoire par
défaut des bibliothèques 64 bits en « lib » :
case $(uname -m) in
x86_64)
sed -e '/m64=/s/lib64/lib/' \
-i.orig gcc/config/i386/t-linux64
;;
esac
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 :
../configure --prefix=/usr \
LD=ld \
--enable-languages=c,c++ \
--disable-multilib \
--disable-bootstrap \
--with-system-zlib
Remarquez que pour d'autres langages, il existe des prérequis qui
ne sont pas encore disponibles. Voir le
la page GCC du livre BLFS pour des instructions sur la manière
de construire tous les langages pris en charge par GCC.
Voici la signification des nouvelles options de
configure :
-
LD=ld
-
Ce paramètre assure que le script configure utilisera le ld
installé par binutils, construit plus tôt dans ce chapitre,
au lieu de la version compilée de manière croisée qui serait
sinon utilisée.
-
--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]](../images/important.png)
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
utiliser toute la pile par défaut, donc augmentez la taille de la
pile avant de lancer les tests :
ulimit -s 32768
Testez les résultats en tant qu'utilisateur non privilégié, mais ne
vous arrêtez pas aux erreurs :
chown -Rv tester .
su tester -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 https://www.linuxfromscratch.org/lfs/build-logs/11.0/
et https://gcc.gnu.org/ml/gcc-testresults/.
Huit tests liés à l'analyseur sont connus pour échouer.
Un test nommé asan_test.C est connu
pour échouer.
Dans libstdc++, un test nommé 49745.cc est connu pour échouer parce que les
dépendances des en-têtes de glibc ont changé.
Dans libstdc++, un test numpunct et six tests liés à get_time sont
connus pour échouer. Tout cela est du aux définitions des
paramètres régionaux dans glibc qui ont changées, mais libstdc++ ne
prend pas encore en charge ces changements.
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é.
Installez le paquet et supprimez un répertoire inutile :
make install
rm -rf /usr/lib/gcc/$(gcc -dumpmachine)/11.2.0/include-fixed/bits/
Le répertoire de construction de GCC appartient maintenant à
tester et la propriété du
répertoire des en-têtes installé (et son contenu) seront
incorrectes. Donnez la propriété à l'utilisateur et au groupe
root :
chown -v -R root:root \
/usr/lib/gcc/*linux-gnu/11.2.0/include{,-fixed}
Créez un lien symbolique requis par le FHS
pour des raisons « historiques ».
ln -svr /usr/bin/cpp /usr/lib
Ajoutez un lien symbolique de compatibilité pour permettre
l'optimisation à l'édition des liens (LTO) à la construction de
programmes :
ln -sfv ../../libexec/gcc/$(gcc -dumpmachine)/11.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/11.2.0/../../../../lib/crt1.o succeeded
/usr/lib/gcc/x86_64-pc-linux-gnu/11.2.0/../../../../lib/crti.o succeeded
/usr/lib/gcc/x86_64-pc-linux-gnu/11.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 porte sur le nom du répertoire
après /usr/lib/gcc. La chose
importante à chercher est que gcc ait trouvé les trois fichiers
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/11.2.0/include
/usr/local/include
/usr/lib/gcc/x86_64-pc-linux-gnu/11.2.0/include-fixed
/usr/include
À nouveau, le nom du répertoire après votre triplet 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 emplacements qui contiennent
« -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 /usr/lib/libc.so.6 succeeded
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 /usr/lib/ld-linux-x86-64.so.2
Si la sortie ne ressemble pas à celle 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. 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