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 Chapter 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.

Quelques points techniques sur la façon dont fonctionne la méthode de construction du Chapter 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 paquet 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.

Ce qui est ensuite installé est les en-têtes de l'API de Linux nettoyées. Elles permettent à la bibliothèque standard (Glibc) d'interagir avec les fonctionnalités que le noyau Linux fournira.

Le paquet suivant 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 les 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 paquet 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.

Lors de la seconde passe de Binutils, nous sommes capables d'utiliser l'option --with-lib-path de configure pour contrôler le chemin de recherche des bibliothèques de ld.

Pour la deuxième passe de GCC, ses sources doivent aussi être modifiées pour dire à GCC d'utiliser le nouvel éditeur de liens dynamiques. Un échec pour faire cela aura pour conséquence que les GCC eux-mêmes auront le même nom que l'éditeur de liens dynamique du répertoire /lib du système hôte embarqué à l'intérieur, ce qui irait à l'encontre de l'objectif de se démarquer de l'hôte. Dans cette optique, l'ensemble d'outils cœur est auto-contenue et auto-hébergé. Le reste des paquets du Chapter 5 se construit contre la nouvelle Glibc de /tools.

Avant d'entrer dans l'environnement chroot dans le Chapter 6, le premier paquet 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.