Notes techniques sur l'ensemble 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 de Chapitre 5 est de fournir un environnement temporaire où nous pouvons utiliser chroot à partir duquel nous pouvons produit une construction propre, sans soucis, du système LFS cible dans Chapitre 6. Tout au long du chemin, nous nous séparons du système hôte autant que possible et, se faisant, nous construisons un ensemble d'outils qui se tient. Il devrait être noté que 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

Avant de continuer, faites attention au nom de la plateforme de travail, souvent appelé la triplette cible. De nombreuses fois, la triplette cible sera probablement i686-pc-linux-gnu. 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 paquetages. Déballez les sources de Binutils, lancez le script ./config.guess et notez la sortie.

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 sera habituellement ld-linux.so.2. Sur des plateformes moins connues, le nom pourrait être ld.so.1 alors que les nouvelles plateformes 64 bits pourraient être nommées encore différemment. Le nom de l'éditeur de liens dynamiques de la plateforme peut être déterminé en cherchant 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 de la hôte système 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 vous pourriez supposer. Un GCC ou une Glibc mal configurée peut résulter en un ensemble d'outils subtilement cassé, où l'impact d'une telle cassure ne se montrerait pas avant la fin de la construction de la distribution complète. Un échec dans la suite de tests surlignera habituellement sur 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/$TARGET_TRIPLET/bin. Les outils dans un emplacement sont liés en dur à l'autre. Une facette importante de l'éditeur de liens est son ordre de recherche des bibliothèques. Des informations détaillées peuvent être obtenues à 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-pc-linux-gnu/bin/as
checking what linker to use... /tools/i686-pc-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.

Des informations détaillées peuvent être obtenues à 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 incluant les chemins de recherche inclus par gcc et leur ordre.

Le prochain paquetage installé est Glibc. Les plus importantes considérations pour construire Glibc est le compilateur, les outils binaires et les en-têtes du noyau. Le compilateur n'est généralement pas un problème car Glibc utilise toujours le gcc trouvé dans un répertoire du PATH. 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="gcc -B/tools/bin/" pour contrôler les outils binaires utilisés, et l'utilisation de -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 se repose généralement pas sur l'ensemble d'outils par défaut.

Après l'installation de Glibc, réalisez les ajustements pour vous assurer que la recherche et l'édition de liens prennent seulement place à l'intérieur du préfixe /tools. Installez un ld ajusté qui a un chemin de recherche limité, codé en dur, vers /tools/lib. Puis, modifiez le fichier specs de gcc pour pointer vers le nouvel éditeur de liens dynamique dans /tools/lib. Cette dernière étape est vitale pour le processus complet. Comme mentionné ci-dessus, 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 <name of binary> | 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.

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 résultera en 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à, l'ensemble 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, réalisez une rapide modification des valeurs par défaut de l'ensemble des outils puis continuez la construction du reste du système LFS cible.