Ré-ajuster l'ensemble de nos outils

Maintenant que les nouvelles et finales bibliothèques C ont été installées, il est temps d'ajuster de nouveau notre ensemble d'outils. Nous allons l'ajuster de façon à ce qu'il soit lié avec les nouvelles bibliothèques. C'est en fait la même chose que ce que nous avons fait dans la phase d'« ajustement » au début du précédent chapitre, même si cela semble être l'inverse : auparavant nous avons guidé l'ensemble des répertoires /{,usr/}lib de l'hôte vers /tools/lib, maintenant nous le guidons du même /tools/lib vers les /{,usr/}lib de LFS.

Tout d'abord, nous ajustons l'éditeur de liens. Pour ceci, nous retenons les répertoires des sources et de construction de la deuxième passe pour Binutils. Installez l'éditeur de liens ajusté à partir du répertoire binutils-build:

make -C ld INSTALL=/tools/bin/install install

Note

Si vous avez oublié le message d'avertissement précédent pour conserver les répertoires des sources et de construction de Binutils à partir de la seconde passe du Chapitre 5 ou si vous les avez supprimé accidentellement ou si vous avez perdu accès à ceux-ci, ne vous inquiétez pas, tout n'est pas perdu. Simplement, ignorez la commande ci-dessus. Cela résultera dans le fait que le prochain paquet, Binutils, sera lié avec les bibliothèques C de /tools au lieu de /{,usr/}lib. Ce n'est pas idéal. Néanmoins, nos tests ont montré que les binaires Binutils devaient être identique.

À partir de maintenant, tout programme compilé sera uniquement lié avec les bibliothèques contenues dans /usr/lib et /lib. INSTALL=/tools/bin/install est nécessaire parce que le Makefile créé durant la seconde passe contient toujours la référence à /usr/bin/install, que nous n'avons pas encore installé. Certaines distributions hôtes contiennent un lien symbolique ginstall qui a la préférence dans le Makefile et donc pourrait proposer un problème ici. La commande ci-dessus s'en occupe aussi.

Vous pouvez maintenant supprimer les répertoires des sources et de construction de Binutils.

La prochaine chose à faire est de modifier le fichier specs de GCC de façon à ce qu'il pointe vers le nouvel éditeur de liens. Comme précédemment, nous utilisons une commande sed pour accomplir ceci:

SPECFILE=/tools/lib/gcc-lib/*/*/specs &&
sed -e 's@ /tools/lib/ld-linux.so.2@ /lib/ld-linux.so.2@g' \
    $SPECFILE > newspecfile &&
mv -f newspecfile $SPECFILE &&
unset SPECFILE

Encore une fois, un copier/coller de ce qui se trouve ci-dessus est recommandé. Et comme précédemment, ce serait une bonne idée d'inspecter visuellement le fichier specs pour s'assurer que les changements souhaités ont réellement eu lieu.

Important

Si vous travaillez sur une plateforme où le nom de l'éditeur de liens dynamiques est autre que ld-linux.so.2, vous devez substituer ld-linux.so.2 avec le nom de l'éditeur de liens dynamiques de votre plateforme. Référez-vous à la section intitulée « Notes techniques sur l'atelier d'outils » si nécessaire.

Caution

Il est impératif à ce point de s'arrêter et de s'assurer que les fonctionnalités de base fonctionnent comme prévu. Nous allons effectuer une simple vérification :

echo 'main(){}' > dummy.c
cc dummy.c
readelf -l a.out | grep ': /lib'

Si tout a fonctionné correctement, la sortie de la dernière commande sera (avec des différences spécifiques à la plateforme dans le nom de l'éditeur de liens) :

[Requesting program interpreter: /lib/ld-linux.so.2]

Notez particulièrement que /lib est maintenant le préfixe de notre éditeur de liens dynamiques.

Si vous n'obtenez pas une sortie comme celle montrée ci-dessus, ou aucune sortie du tout, alors quelque chose va très mal. Vous devrez enquêter là-dessus et reprendre chaque étape pour trouver où est situé le problème et le corriger. Il ne sert à rien de continuer jusqu'à ce que ce soit corrigé. Il est probable que quelque chose s'est mal passé avec le fichier specs ci-dessus.

Une fois satisfait, nettoyez les fichiers de test :

rm dummy.c a.out