Cette section essaie d'expliquer quelques détails techniques et logiques concernant la méthode de construction. Il n'est pas essentiel de comprendre tout immédiatement. La plupart des explications prendra du sens une fois que vous aurez réalisé une construction complète. Vous pouvez aussi vous y référer plus tard.

Le but global du Chapitre 5 est d'apporter un environnement sain et temporaire dans lequel nous pouvons entrer avec chroot et à partir duquel nous pouvons constuire un système LFS propre, sans problème lors du Chapitre 6. Pendant ce temps, nous essayons de nous séparer du système hôte autant que possible en créant un atelier (ensemble d'outils) qui se suffit. Il doit être noté que le processus de construction a été réalisé d'une telle façon que les risques sont minimisés pour les nouveaux lecteurs et qu'il apporte une valeur éducationnelle maximum en même temps. En d'autres termes, des techniques plus avancées pourraient être utilisées pour construire le système.

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

Binutils est installé en premier parce que la commande ./configure de GCC et Glibc réalise des tests de fonctionnalités sur l'assembleur et l'éditeur de liens durant leur lancement respectif de ./configure pour déterminer les fonctionnalités (dés)activées pour le logiciel. Ceci est plus important que ce que vous pouvez imaginer. Un GCC ou Glibc mal configuré peut résulter en un ensemble d'outils subtilement bogué où l'impact d'une telle erreur n'apparaîtra qu'à la fin de la construction de la distribution complète. Heureusement, un échec de la suite de tests nous alertera habituellement avant que trop de temps ne se soit passé.

Binutils installe son assembleur et son éditeur de liens en deux emplacements, /tools/bin et /tools/$TRIPLET_CIBLE/bin. En fait, les outils dans un emplacement sont des liens vers les autres. Une importante facette de l'éditeur de liens réside dans l'ordre de son chemin de recherche des bibliothèques. Des informations détaillées sont disponibles sur ld en lui passant l'option --verbose. Par exemple, ld --verbose | grep SEARCH vous montrera le chemin actuel et leur ordre. Vous pouvez voir quels fichiers sont actuellement liés par ld en compilant un programme et en ajoutant l'option --verbose. Par exemple, gcc dummy.c -Wl,--verbose 2>&1 | grep succeeded vous affichera tous les fichiers ouverts avec succès lors du lien.

Le prochain paquet installé est GCC et, lors de exécution de ./configure, vous verrez par exemple :

Ceci est important pour les raisons mentionnées ci-dessus. Cela démontre aussi que le script configure de GCC ne cherche pas les outils à utiliser dans les répertoires PATH. Néanmoins, lors des opérations sur gcc lui-même, les mêmes chemins de recherche ne sont pas nécessairement utilisés. Vous pouvez trouver quel éditeur de liens standard gcc va utiliser en lançant : gcc -print-prog-name=ld. Des informations détaillées peuvent être obtenues à partir de gcc en lui passant l'option -v lors de la compilation d'un programme. Par exemple, gcc -v dummy.c vous affichera des informations sur le préprocesseur, les étapes de compilation et d'assemblage en incluant les chemins de recherche des en-têtes de gcc ainsi que leur ordre.

Le prochaine paquet installé est Glibc. Les considérations les plus importantes lors de la compilation de Glibc sont le compilateur, les outils Le compilateur n'est généralement pas un problème car Glibc utilise toujours le gcc trouvé dans un répertoire de PATH. Les outils binaires et les en-têtes du noyau peuvent poser plus de problèmes. Donc, nous ne prenons aucun risque et utilisons les options disponibles par configure. Après le lancement de ./configure, vous pouvez vérifier le contenu du fichier config.make du répertoire glibc-build pour tous les détails importantes. Vous noterez des éléments intéressants comme l'utilisation de CC="gcc -B/tools/bin/" pour contrôler quels outils binaires sont utilisés, mais aussi l'utilisation des options -nostdinc et -isystem pour contrôler le chemin de recherche des fichiers include du compilateur. Ces éléments aident à souligner un aspect important du paquet Glibc : il est tout à fait suffisant en terme de machinerie de construction et ne repose pas en général sur les valeurs par défaut de l'ensemble des outils.

Après l'installation de Glibc, nous faisons quelques ajustements pour nous assurer que la recherche et l'édition de liens prennent place dans notre préfixe /tools. Nous installons un ld personnalisé, disposant d'un chemin de recherche en dur vers /tools/lib. Ensuite, nous modifions le fichier specs de gcc pour pointer vers notre éditeur de liens dynamiques dans /tools/lib. Cette dernière étape est vitale pour tout le processus. Comme mentionné ci-dessus, un chemin codé en dur vers un éditeur de liens dynamiques est embarqué dans chaque exécutable ELF. Vous pouvez l'inspecter en lançant : readelf -l <nom du binaire> | grep interpreter. En modifiant le fichier specs de gcc, nous nous assurons que tout programme compilé ici (et jusqu'à la fin du Chapitre 5) utilisera notre nouvel éditeur de liens compris dans /tools/lib.

Le besoin d'utiliser le nouvel éditeur de liens dynamiques est aussi la raison pour laquelle nous appliquons le correctif Specs lors de la deuxième passe pour GCC. Échouer en ce faisant résultera en des programmes GCC comprenant le nom de l'éditeur de liens du répertoire /lib sur le système hôte, ce qui ferait échouer notre but de s'éloigner de l'hôte.

Lors de la deuxième passe pour Binutils, nous sommes capable d'utiliser l'option configure --with-lib-path pour contrôler le chemin de recherche de la bibliothèque de ld. À partir de ce moment, notre atelier principal d'outils se suffit à lui-même. Le reste des paquets du Chapitre 5 sera construit avec le répertoire /tools.

En entrant dans l'environnement chroot du Chapitre 6, le premier paquet majeur que nous installons est Glibc, dûe à sa nature auto-suffisante. Une fois que cette Glibc est installée dans /usr, nous réalisons un rapide changement dans les paramètres par défaut de l'atelier des outils, puis procédons à la construction du reste de la cible LFS.