Linux From Scratch - Version 5.1.1 |
||
|---|---|---|
Chapitre 5. Construire un système temporaire |
||
|
|
|
Linux From Scratch - Version 5.1.1 |
||
|---|---|---|
Chapitre 5. Construire un système temporaire |
||
|
|
|
|
Maintenant que les bibliothèques C temporaires ont été installées, nous voulons que tous les outils compilés dans le reste de ce chapitre soient liés avec ces bibliothèques. Pour accomplir cela, nous avons besoin d'ajuster l'éditeur de liens et le fichier specs du compilateur. Certaines personnes diront que cela ressemble à de la « magie noire », mais c'est vraiment très simple.
Tout d'abord, installez l'éditeur de liens ajusté (à la fin de la première passe de Binutils) 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)
Si vous avez manqué l'avertissement précédent de différencier les répertoires source et de conversion de Binutils à partir de la première passe ou que vous l'avez supprimé accidentellement ou encore si vous n'y avez plus accès, ne vous inquiétez pas, tout n'est pas perdu. 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é, vous devez supprimer les répertoires source et de construction de Binutils.
La prochaine chose à faire est de modifier le fichier specs de GCC pour qu'il pointe vers le nouvel éditeur de liens. Une simple commande sed devrait y parvenir :
SPECFILE=/tools/lib/gcc-lib/*/*/specs &&
sed -e 's@ /lib/ld-linux.so.2@ /tools/lib/ld-linux.so.2@g' \
$SPECFILE > tempspecfile &&
mv -f tempspecfile $SPECFILE &&
unset SPECFILE
Nous recommandons que vous copiez/collez les commandes ci-dessus plutôt que d'essayer de les taper entièrement. Ou vous pouvez éditer le fichier specs manuellement si vous le voulez : remplacez seulement les occurences de « /lib/ld-linux.so.2 » avec « /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)
Si vous travaillez sur une plateforme où le nom de l'éditeur de liens est quelque chose d'autre que ld-linux.so.2, vous devez remplacer ld-linux.so.2 avec le nom de l'éditeur de liens de votre plateforme dans les commandes ci-dessus. Référez-vous à la section intitulée « Notes techniques sur l'atelier 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. Nous allons expliquer un peu plus ceci dans ce chapitre. Pour l'instant, lancez les commandes suivantes pour éliminer cette possibilité :
rm -f /tools/lib/gcc-lib/*/*/include/{pthread.h,bits/sigthread.h}
![[Caution]](../images/caution.png)
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 nous nous y attendons. Pour cela, nous allons lancer une vérification de santé :
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 (dépendant des différences spécifiques aux plateformes sur le nom de l'éditeur de liens) :
[Requesting program interpreter: /tools/lib/ld-linux.so.2]
Notez spécialement que /tools/lib apparaît comme préfixe de notre chargeur dynamique.
Si vous n'avez pas obtenu la sortie montrée ci-dessus ou si vous n'avez reçu aucune sortie, alors quelque chose ne se passe pas bien. Vous devez donc investiguer et retracer vos étapes pour trouver où se cache le problème et comment le corriger. Il n'y a aucune raison pour continuer tant que ceci n'est pas fait. Tout d'abord, relancez la vérification en utilisant gcc au lieu de cc. Si cela fonctionne, cela signifie que le lien symbolique /tools/bin/cc est manquant. Revisitez la section intitulée « GCC-3.3.3 - Passe 1 » et corrigez le lien symbolique. Ensuite, assurez-vous que votre PATH est correct. Vous pouvez vérifier ceci 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 la section intitulée « Configurer l'environnement ». Enfin, quelque chose de mal a pu 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 dummy.c a.out
|
|
|
|
| Glibc-2.3.3-lfs-5.1 |
|
Tcl-8.4.6 |