GCC-3.3.3 - Passe 2

Temps de construction approximatif :  11,0 SBU
Espace disque requis :                332,7 Mo

Re-installation de GCC

Les outils requis pour tester GCC et Binutils sont maintenant installés : Tcl, Expect et DejaGnu. Nous pouvons reconstruire GCC et Binutils en les liant avec la nouvelle Glibc et en les testant correctement (si vous souhaitez lancer les suites de tests dans ce chapitre). Une chose à noter, néanmoins, est que ces suites de tests dépendent énormément de pseudos terminaux (PTY) fonctionnels fournis par votre distribution hôte. Ces jours-ci, les PTY sont le plus souvent implémentés via le système de fichiers devpts. Vous pouvez rapidement vérifier si votre 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, votre 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. Vous pouvez consulter le Wiki LFS sur http://wiki.linuxfromscratch.org/ pour plus d'informations sur la façon de faire fonctionner les PTY.

Cette fois-ci, nous allons construire à la fois les compilateurs C et C++, donc vous devrez déballer les archives core et g++ (et aussi la suite de tests si vous souhaitez lancer les tests). Déballez-les dans votre répertoire de travail, ils iront tous dans un seul sous-répertoire gcc-3.3.3/.

Tout d'abord, corrigez un problème et faites un ajustement essentiel :

patch -Np1 -i ../gcc-3.3.3-no_fixincludes-1.patch
patch -Np1 -i ../gcc-3.3.3-specs-1.patch

Le premier correctif désactive le script GCC « fixincludes ». Nous l'avions 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 votre 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 votre système devraient être corrigés, les corriger et les placer dans le répertoire des en-têtes privés de GCC. Plus tard 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 notre é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.

[Important]

Important

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.3.3/configure --prefix=/tools \
    --with-local-prefix=/tools \
    --enable-clocale=gnu --enable-shared \
    --enable-threads=posix --enable-__cxa_atexit \
    --enable-languages=c,c++

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, les personnes qui n'installent pas la locale de_DE courent le risque de construire les bibliothèques C++ incompatibles avec ABI dû au mauvais modèle de locale, generic, sélectionné.

  • --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, et est essentiel 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.

Compilez le paquet :

make

Il n'est pas nécessaire d'utiliser la cible bootstrap maintenant car le compilateur que nous utilisons 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, nous ne vous recommandons pas de lancer les suites de test pour les outils temporaires de ce chapitre. Si vous souhaitez toujours lancer la suite de tests GCC, la commande suivante le fera :

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.3.3/contrib/test_summary

(Pour un simple résumé, envoyez la sortie sur un tube suivi de grep -A7 Summ.)

Vous pouvez comparer vos résultats avec ceux postés sur la liste de diffusion gcc-testresults pour des configurations similaires à la vôtre. Pour un exemple concernant la version actuelle GCC-3.3.3 sur un i686-pc-linux-gnu, voir http://gcc.gnu.org/ml/gcc-testresults/2004-01/msg00826.html.

Notez que les résultats contiennent :

* 1 XPASS (unexpected pass) for g++
* 1 FAIL (unexpected failure) for gcc
* 24 XPASS's for libstdc++

La partie échouée pour g++ est dûe à l'utilisation de --enable-__cxa_atexit. Apparemment, toutes les plateformes supportées par GCC ne disposent pas du support de « __cxa_atexit » dans leur bibliothèque C, donc il est probable que ce test ne réussira pas.

Les 24 parties échouées pour libstdc++ sont dûes à l'utilisation de --enable-clocale=gnu. Cette option, qui est le bon choix pour des systèmes basés sur Glibc, versions 2.2.5 et supérieures, active dans la bibliothèque GNU C un support locale qui est supérieur à l'autre modèle générique (qui pourrait être applicable si, par exemple, vous utilisiez Newlibc, Sun-libc ou toute autre libc). La suite de tests libstdc++ s'attend apparemment au modèle générique, donc ces tests ne sont pas supposé réussir.

Avoir quelques échecs inattendus ne peut souvent pas être éviter. Les développeurs GCC sont généralement au courant mais n'ont pas encore réussi à les corriger. Un exemple particulier est celui du test filebuf_members dans la suite de tests de la bibliothèque standard C++. Ce test a échoué dans différentes situations mais réussi dans d'autres. En bref, sauf si vos tests sont grandement différents de ceux de l'URL ci-dessus, vous pouvez continuer sans crainte.

Et finalement, installez le paquet :

make install
[Note]

Note

À 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 petit test de compilation. Si les résultats sont mauvais, alors vous avez probablement oublié d'appliquer le correctif "GCC Specs" mentionné ci-dessus.

Les détails sur ce paquet sont disponibles dans la section intitulée « Contenu de GCC ».