5.7. Ajuster l'atelier des outils
Maintenant que les bibliothèques C temporaires ont été installées, tous les outils compilés dans le reste de ce chapitre doivent être liés avec ces bibliothèques. Pour accomplir cela, l'éditeur de liens et le fichier specs du compilateur doivent être ajustés.
L'éditeur de liens ajusté (à la fin de la première passe de Binutils) est installé en lançant la commande suivante à partir du répertoire binutils-build :
make -C ld install
À partir de ce moment, tout sera lié uniquement avec les bibliothèques comprises dans /tools/lib.
![[Note]](../images/note.png)
Note
Si l'avertissement précédent de différencier les répertoires source et de conversion de Binutils à partir de la première passe n'a pas été suivi, ignorez simplement la commande ci-dessus. Le résultat en est une petite chance de programmes de tests toujours liés avec les bibliothèques de l'hôte. Ce n'est pas idéal mais ce n'est pas un problème majeur. La situation est corrigée à l'installation de la deuxième passe de Binutils un peu plus tard.
Maintenant que l'éditeur de liens ajusté est installé, les répertoires source et de construction de Binutils doivent être supprimés.
La prochaine tâche est de modifier le fichier specs de GCC pour qu'il pointe vers le nouvel éditeur de liens. Un simple script sed devrait y parvenir :
SPECFILE=`gcc --print-file specs` &&
sed 's@ /lib/ld-linux.so.2@ /tools/lib/ld-linux.so.2@g' \
$SPECFILE > tempspecfile &&
mv -f tempspecfile $SPECFILE &&
unset SPECFILE
Il est recommandé que la commande ci-dessus soit copiée/collée pour assurer la précision de la commande. Autrement, le fichier specs est éditable manuellement. Ceci est fait en remplaçant chaque occurrence de « /lib/ld-linux.so.2 » par « /tools/lib/ld-linux.so.2 ».
Assurez-vous d'inspecter visuellement le fichier specs pour vérifier que la modification attendue a été réellement réalisée.
![[Important]](../images/important.png)
Important
Au cas où le nom de l'éditeur de liens de la plateforme de travail est autre que ld-linux.so.2, remplacez ld-linux.so.2 avec le nom de l'éditeur de liens de votre plateforme dans les commandes ci-dessus. Référez-vous à Section 5.2, « Notes techniques sur l'ensemble d'outils, » si nécessaire.
Enfin, il existe un risque que certains fichiers include du système hôte aient trouvé leur chemin vers le répertoire include privé de GCC. Ceci peut arriver à cause du processus « fixincludes » de GCC fonctionnant en tant que partie de la construction GCC. Ceci est expliquer un peu plus tard dans ce chapitre. Lancez les commandes suivantes pour éliminer cette possibilité :
rm -vf /tools/lib/gcc/*/*/include/{pthread.h,bits/sigthread.h}
![[Attention]](../images/caution.png)
Attention
Il est impératif à ce moment de s'arrêter et de s'assurer que les fonctions basiques (compilation et édition des liens) du nouvel atelier d'outils fonctionnent comme attendu. Pour réaliser une vérification de santé, lancez les commandes suivantes :
echo 'main(){}' > dummy.c
cc dummy.c
readelf -l a.out | grep ': /tools'
Si tout fonctionne correctement, il ne devrait pas y avoir d'erreurs et la sortie de la dernière commande sera de la forme :
[Requesting program interpreter:
/tools/lib/ld-linux.so.2]
Notez que /tools/lib apparaît comme préfixe du chargeur dynamique.
Si l'affichage diffère ou s'il n'y a aucun affichage, alors quelque chose ne se passe pas bien. Investiguez et retracez vos étapes pour trouver où se cache le problème et comment le corriger. Ce problème doit être corrigé avant de continuer. Tout d'abord, relancez la vérification en utilisant gcc au lieu de cc. Si cela fonctionne, le lien symbolique /tools/bin/cc est manquant. Revisitez Section 5.4, « GCC-3.4.3 - Passe 1, » et installez le lien symbolique. Ensuite, assurez-vous que le PATH est correct. Ceci se vérifie en lançant echo $PATH et en vérifiant que /tools/bin est en tête de la liste. Si le PATH est mauvais, cela pourrait signifier que vous n'êtes pas connecté en tant qu'utilisateur lfs ou que quelque chose s'est mal passé dans Section 4.4, « Configurer l'environnement. » Une autre possibilité est que quelque chose a pu mal se passer avec la correction du fichier specs ci-dessus. Dans ce cas, refaites la modification de ce fichier en vous assurant de copier/coller les lignes comme cela était recommandé.
Une fois satisfait, nettoyez les fichiers de test :
rm -v dummy.c a.out
Construire TCL dans la prochaine section servira comme vérification supplémentaire de la bonne mise en place de l'outil de construction. Si TCL échoue à la construction, c'est une indication d'un problème avec l'installation de Binutils, GCC ou Glibc, mais pas avec TCL lui-même.