ii. Remarques techniques sur la chaîne de compilation

À propos de la compilation croisée

La compilation croisée utilise certains concepts qui mériteraient une section à part. Même si vous pouvez passer cette section lors de votre première lecture, nous vous recommandons fortement d'y revenir plus tard pour bien comprendre le processus de construction.

Définissons d'abord certains termes utilisés dans ce contexte.

Par exemple, imaginons le scénario suivant (parfois appelé « Canadian Cross ») : nous avons un compilateur sur une machine lente, que nous appellerons A, et le compilateur ccA. Nous avons également une machine rapide (B), mais aucun compilateur pour (B). Nous voulons produire du code pour une troisième machine, lente cette fois (C). Il y a trois étapes à suivre pour construire un compilateur destiné à la machine C.

Ensuite, tous les programmes requis par la machine C peuvent être compilés avec cc2 sur la machine rapide B. À moins que B ne puisse lancer les programmes produits pour C, il n'existe aucun moyen de tester les nouveaux programmes construits avant de les lancer sur la machine C. Par exemple, pour tester ccC, nous pouvons ajouter une quatrième étape :

Dans l'exemple ci-dessus, seuls cc1 et cc2 sont des compilateurs croisés, c'est-à-dire qu'ils produisent du code pour une machine différente de celle sur laquelle ils tournent. Les autres compilateurs ccA et ccC produisent du code pour la machine sur laquelle ils tournent. Ces compilateurs sont appelés compilateurs natifs.

Implémentation de la compilation croisée dans LFS

Il y a deux points clés pour une compilation croisée :

Pour compiler un paquet de manière croisée pour le système LFS temporaire, le nom du triplet système est légèrement ajusté en modifiant le champ "fabriquant" dans la variable LFS_TGT pour qu'il indique "lfs" et LFS_TGT est ensuite spécifié comme triplet « hôte » via --host, pour que la chaîne d'outils croisée puisse être utilisée pour générer et traiter le code machine qui s'exécute dans le système LFS temporaire. De plus, nous devons activer le « mode de compilation croisée » : bien que le code machine de « l'hôte », c.-à-d. le code machine pour le système LFS temporaire, puisse s'exécuter sur le CPU actuel, il peut référencer des bibliothèques qui ne sont pas disponibles sur « la construction » (la distribution hôte), ou bien du code ou de la donnée pourrait ne pas exister ou être défini différemment dans ces bibliothèques même si elles existent. Lors de la compilation croisée d'un paquet pour le système LFS temporaire, nous ne pouvons pas nous reposer sur le script configure pour détecter ce problème avec le programme simple : il utilise seulement quelques composants de la libc que la libc de la distribution hôte fournit probablement (à moins que la distribution hôte n'utilise une implémentation de la libc différente, comme Musl). Ce programme n'échouera donc pas, contrairement aux programmes vraiment utiles. Ainsi, nous devons spécifier explicitement le triplet de « la construction » pour activer le « mode de compilation croisée ». La valeur que nous utilisons est simplement la valeur par défaut, c.-à-d. le triplet système original de la sortie de config.guess, mais le « mode de compilation croisée » dépend d'une définition explicite comme nous l'avons indiqué.

Nous utilisons l'option --with-sysroot lors de la construction de l'éditeur des liens croisé et du compilateur croisé, pour leur dire où trouver les fichiers requis pour « l'hôte ». Cela s'assure presque qu'aucun autre programme construit dans Chapitre 6 puisse se lier aux bibliothèques de « la construction ». Nous utilisons le mot « presque » car libtool, une enveloppe de « compatibilité » du compilateur et de l'éditeur des liens pour les systèmes de construction basés sur autoconf, peut essayer d'être trop intelligent et passer par erreur des options qui permettent à l'éditeur des liens de trouver les bibliothèques de « la construction ». Pour éviter ce désastre, nous devons supprimer les fichiers d'archives libtool (.la) et corriger une ancienne copie de libtool fournie dans le code de Binutils.

Dans le tableau précédent, « sur pc » signifie que les commandes sont exécutées sur une machine qui utilise la distribution déjà installée. « Sur lfs » signifie que les commandes sont exécutées dans un environnement chroot.

Ce n'est pas la fin de l'histoire. Le langage C n'est pas seulement un compilateur, mais il définit aussi une bibliothèque standard. Dans ce livre, nous utilisons la bibliothèque C de GNU, appelée glibc (son alternative étant « musl »). Cette bibliothèque doit être compilée pour la machine LFS, c'est-à-dire à l’aide du compilateur croisé cc1. Mais le compilateur lui-même utilise une bibliothèque interne qui exécute des instructions complexes indisponibles dans le jeu d'instructions de l'assembleur. Cette bibliothèque interne, libgcc, doit être liée à la bibliothèque glibc pour fonctionner correctement ! De plus, la bibliothèque standard C++ (libstdc++) a aussi besoin d'être associée à glibc. La solution à ce problème consiste d'abord à construire une libgcc inférieure basée sur cc1, qui ne dispose pas de fonctionnalités avancées comme les threads et le traitement des exceptions, puis de construire glibc avec ce compilateur inférieur (glibc elle-même n'étant pas inférieure), puis de construire libstdc++. Cette bibliothèque ne dispose pas des fonctionnalités avancées de libgcc.

La conséquence du paragraphe précédent est que cc1 est incapable de construire une libstdc++ complètement fonctionnelle avec la libgcc dégradée, mais cc1 est le seul compilateur disponible pour construire les bibliothèques C/C++ à la deuxième étape. Comme indiqué, nous ne pouvons pas exécuter cc-lfs sur pc (la distribution hôte) car il peut nécessiter certaines bibliothèques, du code ou des données qui ne sont pas disponibles sur « la construction » (la distribution hôte). Ainsi, lorsque nous construisons la deuxième étape de gcc, nous remplaçons le chemin de recherche des bibliothèques pour se lier à libstdc++ de la libgcc nouvellement reconstruite au lieu de l'ancienne construction dégradée. Cela rend la libstdc++ reconstruite complètement fonctionnelle.

Dans le Chapitre 8, (ou « l’étape 3 »), tous les paquets nécessaires au système LFS sont construits. Même si vous avez déjà installé un paquet sur le système LFS dans un chapitre précédent, vous devrez reconstruire le paquet, à moins d’être certain qu’il n’est pas nécessaire. La stabilisation de ces paquets est la raison principale de leur reconstruction : si vous réinstallez un paquet LFS sur un système complet LFS, le contenu du paquet installé devrait être identique au contenu de ce paquet installé dans le Chapitre 8. Les paquets temporaires installés dans le Chapitre 6 ou le Chapitre 7 ne sont pas concernés, car certaines fonctionnalités facultatives sont désactivées à cause de dépendances manquantes ou du « mode de compilation croisée » . De plus, en reconstruisant les paquets, vous permettez l’exécution de la suite de tests.

Détails supplémentaires de procédure

Le compilateur croisé sera installé dans un répertoire $LFS/tools séparé, puisqu’il ne fera pas partie du système final.

Binutils est installé en premier parce que la commande configure de gcc et glibc effectuent des tests de fonctionnalités sur l'assembleur et l'éditeur de liens pour déterminer quelles fonctionnalités logicielles activer ou désactiver. Cette installation est plus importante que ce que vous pouvez penser. Un gcc ou une glibc mal configurés peuvent casser la chaîne de compilation, et l'impact d’une telle configuration ne se verrait qu’à la fin de la construction de la distribution complète. La suite de tests indiquera généralement cette erreur avant que vous n’ayez trop avancé.

Binutils installe son assembleur et son éditeur de liens à deux emplacements, $LFS/tools/bin et $LFS/tools/$LFS_TGT/bin. Les outils situés à un emplacement sont liés à l’autre par un lien en dur. L’ordre de recherche des bibliothèques est un aspect important de l’éditeur de liens. Vous pouvez obtenir des informations détaillées à partir de la commande ld en lui passant l’option --verbose. Par exemple, la commande ld --verbose | grep SEARCH affichera les chemins de recherche actuels et leur ordre. Cet exemple peut être exécuté en mode lecture par l’utilisateur lfs. Si vous revenez plus tard sur cette page, remplacez la commande $LFS_TGT-ld par ld.

Le prochain paquet installé est gcc. Voici un exemple de ce qui peut s’afficher pendant l'exécution de la commande configure :

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

Il s’agit d’un paquet important pour les raisons mentionnées plus haut. C’est également la preuve que le script configure de gcc ne parcourt pas les répertoires du PATH pour trouver quels outils utiliser. Cependant, lors de l’exécution normale de la commande gcc, les mêmes chemins de recherche ne sont pas forcément utilisés. Pour trouver quel éditeur de liens standard gcc utilise, exécutez la commande $LFS_TGT-gcc -print-prog-name=ld. À nouveau, retirez la commande $LFS_TGT- si vous revenez ici plus tard.

Vous pouvez obtenir des informations détaillées grâce à la commande gcc en lui passant l’option -v lors de la compilation d'un programme. Par exemple, la commande $LFS_TGT-gcc -v example.c (sans $LFS_TGT- si vous revenez plus tard) affichera des informations détaillées sur les phases de préprocesseur, de compilation et d’assemblage, ainsi que les chemins de recherche de gcc pour les en-têtes inclus et leur ordre.

L’installation suivante concerne les en-têtes nettoyés de l’API de Linux. Ils permettent à la bibliothèque standard C (glibc) d’interagir avec les fonctionnalités fournies par le noyau Linux.

Ensuite vient glibc. C'est le premier paquet que nous compilons de manière croisée. Nous utilisons l'option --host=$LFS_TGT pour faire utiliser ces outils préfixés par $LFS_TGT au système de construction, et l'option --build=$(../scripts/config.guess) pour activer le « mode de compilation croisée » comme indiqué. La variable DESTDIR est utilisée pour forcer l'installation dans le système de fichiers LFS.

Comme indiqué précédemment, la bibliothèque standard C++ est ensuite compilée, suivie dans le Chapitre 6 par les autres programmes qui nécessitent une compilation croisée en raison des dépendances circulaires qu’ils cassent lors de la construction. Les étapes pour ces paquets sont similaires aux étapes pour glibc.

À la fin du Chapitre 6, le compilateur LFS natif est installé. binutils-pass2 est construit en premier, avec le même répertoire d’installation DESTDIR que les autres programmes, puis la deuxième passe de gcc est construite sans les bibliothèques inutiles.

À l’entrée de l'environnement chroot dans le Chapitre 7, les programmes nécessaires au bon fonctionnement de la chaîne de compilation sont installés de manière temporaire. À partir de là, la chaîne de construction de base est auto-suffisante et auto-hébergée. Dans le Chapitre 8, vous construirez, testerez et installerez les versions finales de tous les paquets nécessaires au bon fonctionnement du système complet.