Ré-ajustement de l'ensemble d'outils

Maintenant que les bibliothèques C finales ont été installées, il est temps d'ajuster de nouveau l'ensemble d'outils. L'ensemble d'outils sera ajusté de façon à ce qu'il lie tout programme nouvellement compilé avec ces nouvelles bibliothèques. C'est le même processus que celui utilisé dans la phase « Ajustement » au début du Chapitre 5, avec les ajustements inversés. Dans Chapitre 5, l'ensemble était passé des répertoires /{,usr/}lib de l'hôte dans le nouveau répertoire /tools/lib. Maintenant, l'ensemble sera guidé du même répertoire /tools/lib vers les répertoires /{,usr/}lib de LFS.

Commencez en ajustant l'éditeur de liens. Les répertoires des sources et de construction de la deuxième passe de Binutils ont été conservés dans ce but. Installez l'éditeur de liens ajusté en exécutant la commande suivante à partir du répertoire binutils-build :

make -C ld INSTALL=/tools/bin/install
install
[Note]

Note

Si le précédent avertissement pour conserver les répertoires des sources et de construction de Binutils lors de la deuxième passe dans Chapitre 5 a été oublié, ou s'ils ont été accidentellement supprimés ou rendus inaccessibles, ignorez la commande ci-dessus. Le résultat en sera que le prochain paquet, Binutils, sera lié aux bibliothèques C dans /tools plutôt que dans /{,usr/}lib. Ceci n'est pas idéal. Néanmoins, les tests ont montrés que les binaires Binutils résultants devraient être identiques.

À partir de maintenant, chaque programme compilé sera lié avec les bibliothèques de /usr/lib et de /lib. L'option supplémentaire INSTALL=/tools/bin/install est nécessaire car le fichier Makefile créé lors de la seconde passe contient toujours la référence à /usr/bin/install, qui n'a pas encore été installé. Quelques distributions hôtes contiennent un lien symbolique ginstall qui est prioritaire dans le fichier Makefile et peut cause un problème. La commande ci-dessus tient compte de ce problème.

Supprimez les répertoires des sources et de construction de Binutils maintenant.

Ensuite, modifiez le fichier specs de GCC pour qu'il pointe sur le nouvel éditeur de liens. Une commande perl accomplit ceci :

perl -pi -e 's@ /tools/lib/ld-linux.so.2@ /lib/ld-linux.so.2@g;' \
    -e 's@\*startfile_prefix_spec:\n@$_/usr/lib/ @g;' \
        `gcc --print-file specs`

C'est une bonne idée d'inspecter visuellement le fichier specs pour vérifier que les modifications attendues ont réellement été effectuées.

[Important]

Important

En travaillant sur une plateforme où le nom de l'éditeur de liens est quelque chose d'autres que ld-linux.so.2, substituez « ld-linux.so.2 » par le nom de l'éditeur de liens dans les commandes suivantes. Référez-vous à la section intitulée « Notes techniques sur l'ensemble d'outils » si nécessaire.

[Caution]

Caution

Il est impératif à ce moment d'arrêter et de vous assurer que le s fonctions basiques (compilation et édition des liens) de l'ensemble des outils ajusté fonctionnent comme attendu. Pour cela, réalisez une petite vérification :

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

Si tout fonctionne correctement, il ne devrait pas y avoir d'erreurs 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:
/lib/ld-linux.so.2]

Notez que /lib est maintenant le préfixe de notre éditeur de liens.

Si la sortie n'apparaît pas comme ce qui est montré ci-dessus ou si aucune sortie n'est renvoyée, alors quelque chose s'est mal passé. Investiguez et retracez les étapes pour savoir d'où vient le problème et comment le corriger. La raison la plus probable est que quelque chose s'est mal passé lors de la modification du fichier specs ci-dessus. Tout problème devra être résolu avant de continuer le processus.

Une fois que tout fonctionne correctement, nettoyez les fichiers tests :

rm dummy.c a.out