Linux From Scratch - Version 6.6

Chapitre 5. Construire un système temporaire

5.2. Notes techniques sur la chaîne d'outils

Cette section explique certains détails rationnels et techniques derrière la méthode de construction. Il n'est pas essentiel de comprendre immédiatement tout ce qui se trouve dans cette section. La plupart des informations seront plus claires après avoir réalisé réellement une construction complète. Cette section peut servir de référence à tout moment lors du processus de construction.

Le but global du Chapitre 5 est de fournir une zone temporaire qui contient un ensemble d'outils connus qui peuvent être isolés du système hôte. En utilisant chroot, les commandes dans le reste des chapitres se cantonneront à cet environnement, en assurant une construction du système LFS cible propre, sans soucis. Le processus de construction a été conçu pour minimiser les risques pour les nouveaux lecteurs et pour fournir une valeur éducative maximale en même temps.

[Important]

Important

Avant de continuer, faites attention au nom de la plateforme de travail, souvent appelée la triplette cible. Une façon simple de déterminer le nom de la triplette cible est de lancer le script config.guess venant avec le source pour un grand nombre de paquets. Déballez les sources de Binutils, lancez le script ./config.guess et notez la sortie. Par exemple, pour un processeur Intel 32 bits moderne, la sortie sera du type i686-pc-linux-gnu.

De même, faites attention au nom de l'éditeur de liens de la plateforme, souvent appelé le chargeur dynamique (à ne pas confondre avec l'éditeur de liens ld faisant partie de Binutils). Le chargeur dynamique fourni par Glibc trouve et charge les bibliothèques partagées nécessaires à un programme pour s'exécuter, puis l'exécute. Le nom de l'éditeur dynamique pour une machine Intel 32 bits sera ld-linux.so.2. Une façon sûre de déterminer le nom de l'éditeur de liens dynamiques est de chercher dans le répertoire /lib du système hôte. Une façon certaine de déterminer le nom est d'inspecter un binaire au hasard du système hôte en exécutant : readelf -l <nom du binaire> | grep interpreter et de noter le résultat. La référence faisant autorité couvrant toutes les plateformes est dans le fichier shlib-versions à la racine du répertoire des sources de Glibc.

Quelques points techniques sur la façon dont fonctionne la méthode de construction Chapitre 5 :

Binutils est tout d'abord installé parce que les exécutions de Glibc et GCC par configure réalisent quelques tests de fonctionnalités sur l'assembleur et l'éditeur de liens pour déterminer quelle fonctionnalité logicielle activer ou désactiver. Ceci est plus important que ce que vous pouvez imaginer. Un GCC ou une Glibc mal configuré peut aboutir à une chaîne d'outils subtilement cassé, et l'impact d'une telle cassure ne se verrait pas avant la fin de la construction de la distribution complète. Un échec dans la suite de tests surlignera habituellement cette erreur avant que trop de travail supplémentaire n'ait été réalisé.

Binutils installe son assembleur et son éditeur de liens à deux endroits, /tools/bin et /tools/$LFS_TGT/bin. Les outils dans un emplacement sont liés en dur à l'autre. Un aspect important de l'éditeur de liens est son ordre de recherche des bibliothèques. Vous pouvez obtenir des informations détaillées à partir de ld en lui passant le commutateur --verbose. Par exemple, un ld --verbose | grep SEARCH illustrera les chemins de recherche réels et leur ordre. Il montre quels fichiers sont liés par ld en compilant un programme de test et en passant le commutateur --verbose à l'éditeur de liens. Par exemple, gcc dummy.c -Wl,--verbose 2>&1 | grep succeeded affichera tous les fichiers ouverts avec succès lors de l'édition des liens.

Le prochain paquetage installé est GCC. Un exemple de ce qui peut être vu pendant son exécution de configure est : 

checking what assembler to use... /tools/i686-lfs-linux-gnu/bin/as
checking what linker to use... /tools/i686-lfs-linux-gnu/bin/ld

C'est important pour les raisons mentionnées ci-dessus. Cela démontre aussi que le script configure de GCC ne cherche pas les répertoires PATH pour trouver les outils à utiliser. Néanmoins, lors d'une opération normale de gcc, les mêmes chemins de recherche ne sont pas forcément utilisés. Pour trouver quel éditeur de liens standard gcc utilisera, lancez : gcc -print-prog-name=ld

Vous pouvez obtenir des informations détaillées à partir de gcc en lui fournissant l'option en ligne de commande -v lors de la compilation d'un programme de tests. Par exemple, gcc -v dummy.c affichera des informations détaillées sur les étapes du préprocesseur, de la compilation et de l'assemblage ceci comprenant les chemins de recherche inclus par gcc et leur ordre.

Le prochain paquetage installé est Glibc. Les choses les plus importantes à prendre en considération pour construire Glibc sont le compilateur, les outils binaires et les en-têtes du noyau. Le compilateur ne pose généralement pas de problème car Glibc utilise toujours le compilateur lié au paramètre --host passé à son script configure, par exemple, dans notre cas, i686-lfs-linux-gnu-gcc. Les outils binaires et les en-têtes du noyau peuvent être un peu plus compliqués. Du coup, ne prenez pas de risque et utilisez les options disponibles de configure pour renforcer les bonnes sélections. Après l'exécution de configure, vérifiez le contenu du fichier config.make dans le répertoire glibc-build pour tous les détails importants. Notez l'utilisation de CC="i686-lfs-gnu-gcc" pour contrôler le outils binaires utilisés, et l'utilisation des commutateurs -nostdinc et -isystem pour contrôler le chemin de recherche des en-têtes du compilateur. Ces éléments soulignent un aspect important du paquetage glibc—il est auto-suffisant en terme de machinerie de construction et ne repose généralement pas sur la chaîne d'outils par défaut.

Après l'installation de Glibc, modifiez le fichier specs de gcc pour pointer vers le nouvel éditeur de liens dynamique dans /tools/lib. Cette dernière étape est vitale en assurant que la recherche et l'édition des liens ne s'opère qu'à l'intérieur du préfixe /tools. Un chemin en dur vers un éditeur de liens est intégré dans chaque exécutable ainsi que dans chaque exécutable partagé (ELF). Ceci peut être inspecté en exécutant : readelf -l <nom du binaire> | grep interpreter. Modifier le fichier specs de gcc nous assure que chaque programme compilé à partir de maintenant et jusqu'à la fin de ce chapitre utilisera le nouvel éditeur de liens dynamiques dans /tools/lib.

Pour la seconde passe de GCC, ses sources doivent être modifiées pour dire à GCC d'utiliser le nouvel éditeur de liens dynamique. Échouer sur ce point aboutira à des programmes GCC ayant le nom de l'éditeur de liens provenant du répertoire /lib Le besoin d'utiliser le nouvel éditeur de liens dynamique est aussi la raison pour laquelle le correctif Specs est appliqué lors de la seconde passe de GCC. Échouer sur ce point aboutira à des programmes GCC ayant le nom de l'éditeur de liens provenant du répertoire /lib du système hôte intégré en eux, ce qui empêchera le but de s'éloigner de l'hôte.

Lors de la seconde passe de Binutils, nous sommes capable d'utiliser l'option --with-lib-path de configure pour contrôler le chemin de recherche des bibliothèques de ld. À partir de là, la chaîne d'outils principal est contenu en lui-même. Le reste des paquetages de Chapitre 5 se construit à partir de la nouvelle Glibc dans /tools.

Avant d'entrer dans l'environnement chroot dans Chapitre 6, le premier paquetage majeur à être installé est Glibc, à cause de sa nature auto-suffisante mentionnée ci-dessus. Une fois que Glibc est installée dans /usr, nous allons réaliser une rapide modification des valeurs par défaut de l'ensemble des outils puis continuer la construction du reste du système LFS cible.