Ce paquet est connu pour avoir des soucis quand les options d'optimisation
par défaut (en incluant les options -march
et
-mcpu
) sont modifiées. Donc, si des variables d'environnement
qui surchargent les optimisations par défaut, telles que CFLAGS
et CXXFLAGS
, ont été définies, supprimez cette initialisation
pour la construction de GCC.
Les outils requis pour tester GCC et Binutils (Tcl, Expect et DejaGnu)
sont maintenant installés. GCC et Binutils peuvent maintenant être reconstruit
en les liant avec la nouvelle Glibc et en les testant correctement (si
vous souhaitez lancer les suites de tests dans ce chapitre). Merci de noter que
ces suites de tests dépendent énormément de pseudos terminaux (PTY) fonctionnels
fournis par votre distribution hôte. Les PTY sont le plus souvent implémentés
via le système de fichiers devpts
.
Vérifiez si le système hôte est correctement configuré en réalisant un simple
test :
expect -c "spawn ls"
Le résultat devrait être :
The system has no more ptys.
Ask your system administrator to create more.
Si vous récupérez le message ci-dessus, la distribution hôte n'est pas correctement configurée pour les PTY. Dans ce cas, il ne sert à rien de lancer les suites de tests de GCC et Binutils jusqu'à la correction de ce problème. Merci de consulter la FAQ LFS sur http://www.linuxfromscratch.org//lfs/faq.html#no-ptys pour plus d'informations sur la façon de faire fonctionner les PTY.
Tout d'abord, corrigez un problème connu et faites un ajustement essentiel :
patch -Np1 -i ../gcc-3.4.3-no_fixincludes-1.patch patch -Np1 -i ../gcc-3.4.3-specs-2.patch
Le premier correctif désactive le script GCC fixincludes. Ceci a déjà été mentionné brièvement mais une explication plus en détail de fixincludes est apportée ici. Sous des circonstances normales, le script GCC fixincludes parcourt le système pour trouver les fichiers d'en-tête qui ont besoin d'être corrigé. Il pourrait trouver que certains des fichiers d'en-têtes de Glibc sur le système devraient être corrigés, les corriger et les placer dans le répertoire des en-têtes privés de GCC. Dans le Chapitre 6, après avoir installé la nouvelle Glibc, ce répertoire serait recherché avant le répertoire include du système, faisant que GCC trouverait les en-têtes corrigés du système hôte qui ne correspondront certainement pas à la version de Glibc actuellement utilisée pour le système LFS.
Le deuxième correctif modifie l'emplacement par défaut de l'éditeur de
liens dynamiques de GCC (généralement ld-linux.so.2
). Il supprime aussi /usr/include
du chemin de recherche des includes
de GCC. Corriger maintenant plutôt qu'ajuster le fichier specs après
l'installation nous assure que l'éditeur de liens dynamiques sera utilisé lors
de la construction de GCC. C'est-à-dire, tous les binaires finaux (et
temporaires) créés lors de la construction seront liés à la nouvelle Glibc.
Les correctifs ci-dessus sont critiques pour s'assurer une construction avec succès. N'oubliez pas de les appliquer.
De nouveau, créez un répertoire de construction séparé :
mkdir ../gcc-build cd ../gcc-build
Avant de commencer la construction de GCC, rappelez-vous de désinitialiser toute variable d'environnement surchargeant les options d'optimisation par défaut.
Maintenant, préparez la compilation de GCC :
../gcc-3.4.3/configure --prefix=/tools \ --libexecdir=/tools/lib --with-local-prefix=/tools \ --enable-clocale=gnu --enable-shared \ --enable-threads=posix --enable-__cxa_atexit \ --enable-languages=c,c++ --disable-libstdcxx-pch
Voici la signification des nouvelles options de configure :
--enable-clocale=gnu
Cette option nous assure que le bon modèle de locale est sélectionné pour les bibliothèques C++ sous toutes les circonstances. Si le script configure trouve la locale de_DE installée, il sélectionnera le bon modèle de locale gnu. Néanmoins, si la locale de_DE n'est pas installée, il existe un risque de construire des bibliothèques C++ incompatibles avec ABI à cause du choix d'un mauvais modèle générique de locale.
--enable-threads=posix
Ceci active la gestion des exceptions C++ pour le code multi-threadé.
--enable-__cxa_atexit
Cette option autorise l'utilisation de __cxa_atexit, plutôt que atexit, pour enregistrer les destructeurs C++ des objets statiques locaux et globaux. Cette option est essentielle pour la gestion des destructeurs en compatibilité complète avec les standards. Il affecte aussi l'ABI C++ et donc résulte en des bibliothèques partagées et des programmes C++ interopérables avec les autres distributions Linux.
--enable-languages=c,c++
Cette option est nécessaire pour s'assurer que les compilateurs C et C++ seront construits.
--disable-libstdcxx-pch
Ce commutateur empêche la construction de l'en-tête précompilé
(PCH) de libstdc++
. Il prend beaucoup
d'espace et nous n'en avons aucune utilité.
Compilez le paquet :
make
Il n'est pas nécessaire d'utiliser la cible bootstrap
maintenant car le compilateur utilisé pour compiler ce GCC a été construit avec
exactement la même version des sources de GCC utilisées précédemment.
La compilation est maintenant terminée. Comme mentionné plus tôt, lancer les suites de test pour les outils temporaires de ce chapitre n'est pas nécessaire. Néanmoins, pour exécuter la suite de tests de GCC, lancez la commande suivante :
make -k check
L'option -k
est utilisée pour faire en sorte que
toute la suite de tests est exécutée et qu'elle ne s'arrête pas au premier
échec. La suite de tests GCC est très complète et il est pratiquement garantie
que certaines erreurs apparaîtront. Pour obtenir un résumé des résultats de la
suite de tests, lancez ceci :
../gcc-3.4.3/contrib/test_summary
Pour un simple résumé, envoyez la sortie sur un tube suivi de
grep -A7 Summ
.
Les résultats peuvent être comparés à ceux postés sur http://www.linuxfromscratch.org/lfs/build-logs/6.1/.
Quelques échecs inattendus ne peuvent souvent pas être évités. Les développeurs GCC sont généralement au courant mais ne les ont pas encore résolus. À moins que vos tests soient grandement différents de ceux de l'URL ci-dessus, vous pouvez continuer sans crainte.
Installez le paquet :
make install
À ce moment, il est fortement recommandé de répéter la vérification que nous avions réalisé dans ce chapitre. Référez-vous à la section intitulée « Ajuster l'atelier des outils » et répétez le test de compilation. Si les résultats sont mauvais, alors la raison probable en est l'oubli de l'application du correctif "GCC Specs" mentionné ci-dessus.
Les détails sur ce paquet sont situés dans la section intitulée « Contenu de GCC »