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.
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 paquetages. 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 :
Un léger ajustement du nom de la plateforme de travail, en
modifiant le champ "vendor" de la triplette cible via la
variable LFS_TGT
, assure que la
première construction de Binutils et de GCC produira un éditeur
de liens et un compilateur croisés compatibles. Au lieu de
produire des binaires pour une autre architecture, l'éditeur de
liens et le compilateur croisés vont produire des binaires
compatibles avec le matériel actuel.
Les bibliothèques temporaires sont compilées de manière croisée. Ceci supprime toute dépendance du système hôte, diminuant les chances que les en-têtes ou les bibliothèques issues du hôte ne corrompent les nouveaux outils et ouvre la possibilité d'une construction de bibliothèques à la fois 32 et 64 bits sur du matériel gérant le 64 bits.
Une manipulation attentionnée du fichier specs
de gcc indique au compilateur
l'éditeur de liens dynamique cible à utiliser.
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 pourriez imaginer. Un GCC ou une Glibc mal configuré peut aboutir à un ensemble 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
l'ensemble 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à,
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
, 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.