Installer GCC-3.3.1 - Pass 2

Réinstallation de GCC

Les outils requis pour tester GCC et Binutils sont maintenant installés (Tcl, Expect et DejaGnu). Nous pouvons continuer en reconstruisant GCC et Binutils, en les liant avec la nouvelle Glibc et en les testant correctement. 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. Actuellement, les PTY sont 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 cela en réalisant un simple test :

expect -c "spawn ls"

Si vous obtenez le message :

The system has no more ptys. Ask your system administrator to create more.

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 pour faire fonctionner les PTY.

Déballez les trois archives tar de GCC (-core, -g++ et -testsuite) dans un seul répertoire. Elles se placeront dans un seul sous-répertoire gcc-3.3.1/.

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

patch -Np1 -i ../gcc-3.3.1-no_fixincludes-2.patch
patch -Np1 -i ../gcc-3.3.1-specs-2.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és. 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 correspondraient certainement pas à la version de Glibc actuellement utilisée pour le système LFS.

Le dernier 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 cela 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 que tous les binaires finaux (et temporaires) créés lors de la construction seront liés à la nouvelle Glibc.

Créez un répertoire de construction séparé de nouveau :

mkdir ../gcc-build
cd ../gcc-build

Avant de commencer la construction de GCC, rappelez de désinitialiser toute variable d'environnement pour surcharger les options d'optimisation par défaut.

Maintenant, préparez la compilation de GCC :

../gcc-3.3.1/configure --prefix=/tools \
    --with-local-prefix=/tools \
    --enable-clocale=gnu --enable-shared \
    --enable-threads=posix --enable-__cxa_atexit \
    --enable-languages=c,c++

La signification des nouvelles options de configure est :

• --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++ destructors des objets statiques locales et globales 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-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 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-languages=c,c++ : Cette option est nécessaire pour s'assurer que les compilateurs C et C++ sont construits.

Compilez le package :

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.

Testez le résultat :

make -k check

L'option -k est utilisée pour faire en sorte que toute la suite de tests soit exécutée et ne s'arrête pas au premier échec. La suite de tests GCC est très complète et il est pratiquement garanti que certaines erreurs apparaîtront. Pour obtenir un résumé des résultats de la suite de tests, lancez ceci :

../gcc-3.3.1/contrib/test_summary | more

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.1 sur un i686-pc-linux-gnu, voir http://gcc.gnu.org/ml/gcc-testresults/2003-08/msg01612.html.

Notez que les résultats contiennent :

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

La partie échouée ("unexpected pass") 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èques C, donc il est probable que ce test ne réussira pas.

Les 26 parties échouées pour libstdc++ sont dues à l'utilisation de --enable-clocale=gnu, qui est le choix correct pour des systèmes basées sur Glibc, versions 2.2.5 et supérieurs. Le support de la locale dans la bibliothèque GNU C est supérieurà l'autre modèle sélectionné ("generic") qui pourrait être applicable si par exemple vous utilisiez Newlibc, Sun-libc ou tout autre libc). La suite de tests libstdc++ attend apparemment le modèle "generic", donc ces tests ne passent pas obligatoirement.

Des échecs inattendues ne peuvent souvent pas être évités. Les développeurs GCC sont habituellement au courant mais n'ont pas encore réussi à les corriger. En bref, sauf si vos résultats sont grandement différents de ceux présents sur l'URL ci-dessus, il est sain de continuer.

Et finalement, installez le package :

make install