2. Linux From Scratch
3. part3intro_toolchaintechnotes
4. French

Next up: sanitized Linux API headers. These allow the standard C library (glibc) to interface with features that the Linux kernel will provide.

L’installation suivante concerne les headeren-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.

Detailed information can be obtained from <command>gcc</command> by passing it the <parameter>-v</parameter> command line option while compiling a program. For example, <command>$LFS_TGT-gcc -v <replaceable>example.c</replaceable></command> (or without <command> $LFS_TGT-</command> if coming back later) will show detailed information about the preprocessor, compilation, and assembly stages, including <command>gcc</command>'s search paths for included headers and their order.

Vous pouvez obtenir des informations détaillées grâce à la commande <command>gcc</command> en lui passant l’option <parameter>-v</parameter> lors de la compilation d'un programme. Par exemple, la commande <command>$LFS_TGT-gcc -v <replaceable>example.c</replaceable></command> (sans <command> $LFS_TGT-</command> 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 <command>gcc</command> pour les headeren-têtes inclus et leur ordre.

Binutils installs its assembler and linker in two locations, <filename class="directory">$LFS/tools/bin</filename> and <filename class="directory">$LFS/tools/$LFS_TGT/bin</filename>. The tools in one location are hard linked to the other. An important facet of the linker is its library search order. Detailed information can be obtained from <command>ld</command> by passing it the <parameter>--verbose</parameter> flag. For example, <command>$LFS_TGT-ld --verbose | grep SEARCH</command> will illustrate the current search paths and their order. (Note that this example can be run as shown only while logged in as user <systemitem class="username">lfs</systemitem>. If you come back to this page later, replace <command>$LFS_TGT-ld</command> with <command>ld</command>).

Binutils installe son assembleur et son éditeur de liens à deux emplacements, <filename class="directory">$LFS/tools/bin</filename> et <filename class="directory">$LFS/tools/$LFS_TGT/bin</filename>. 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 <command>ld</command> en lui passant l’option <parameter>--verbose</parameter>. Par exemple, la commande <command>ld --verbose | grep SEARCH</command> affichera les chemins de recherche actuels et leur ordre. Cet exemple peut être exécuté en mode lecture par l’utilisateur <systemitem class="username">lfs</systemitem>. Si vous revenez plus tard sur cette page, remplacez la commande <command>$LFS_TGT-ld</command> par <command>ld</command>.

In &ch-final; (or <quote>stage 3</quote>), all the packages needed for the LFS system are built. Even if a package has already been installed into the LFS system in a previous chapter, we still rebuild the package. The main reason for rebuilding these packages is to make them stable: if we reinstall an LFS package on a completed LFS system, the reinstalled content of the package should be the same as the content of the same package when first installed in &ch-final;. The temporary packages installed in &ch-tmp-cross; or &ch-tmp-chroot; cannot satisfy this requirement, because some of them are built without optional dependencies, and autoconf cannot perform some feature checks in &ch-tmp-cross; because of cross-compilation, causing the temporary packages to lack optional features, or use suboptimal code routines. Additionally, a minor reason for rebuilding the packages is to run the test suites.

Dans le &ch-final;, (ou <quote>l’étape  3</quote>), 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&nbsp;: 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 &ch-final;. Les paquets temporaires installés dans le &ch-tmp-cross; ou le &ch-tmp-chroot; ne sont pas concernés, car certains d’entre eux sont construits sans dépendance optionnelle, et autoconf ne peut pas exécuter certaines vérifications dans le &ch-tmp-cross; à cause de la compilation croisée. Les paquets temporaires ne disposent donc pas de certaines fonctionnalités optionnelles ou utilisent des routines sous-optimales. De plus, en reconstruisant les paquets, vous permettez l’exécution de la suite de tests.

So when we build gcc stage 2, we instruct the building system to rebuild libgcc and libstdc++ with cc1, but we link libstdc++ to the newly rebuilt libgcc instead of the old, degraded build. This makes the rebuilt libstdc++ fully functional.

Ainsi, lorsque nous construisons l’étape 2 du 2 de gcc, nous demandons au système de construction de reconstruire libgcc et libstdc++ avec cc1, mais nous lions libstdc++ à lau nouveaulle libgcc reconstruite plutôt qu’à l'ancienne construction dégradée, pour faire en sorte que lea libstdc++ reconstruite soit entièrement opérationnelle.

In order to fake a cross-compilation in LFS, the name of the host triplet is slightly adjusted by changing the &quot;vendor&quot; field in the <envar>LFS_TGT</envar> variable so it says &quot;lfs&quot;. We also use the <parameter>--with-sysroot</parameter> option when building the cross-linker and cross-compiler, to tell them where to find the needed host files. This ensures that none of the other programs built in <xref linkend="chapter-temporary-tools"/> can link to libraries on the build machine. Only two stages are mandatory, plus one more for tests.

Pour simuler une compilation croisée dans LFS, le nom du triplet hôte est légèrement modifié en changeant le champ «&nbsp;fabriquant&nbsp;» dans la variable d’environnement <envar>LFS_TGT</envar> pour qu’il indique «&nbsp;lfs&nbsp;. Nous utilisons également l'option <parameter>--with-sysroot</parameter> lors de la construction de l'éditeur de liens et du compilateur croisés pour leur indiquer l’emplacement des fichiers hôte requis. Cette option permet de s’assurer qu'aucun autre programme construit dans le <xref linkend="chapter-temporary-tools"/> ne peut s’associer aux bibliothèques sur la machine de construction. Seules deux étapes sont obligatoires, en plus d’une étape supplémentaire destinée aux tests.

You should also be aware of the name of the platform's dynamic linker, often referred to as the dynamic loader (not to be confused with the standard linker <command>ld</command> that is part of binutils). The dynamic linker provided by package glibc finds and loads the shared libraries needed by a program, prepares the program to run, and then runs it. The name of the dynamic linker for a 32-bit Intel machine is <filename class="libraryfile">ld-linux.so.2</filename>; it's <filename class="libraryfile">ld-linux-x86-64.so.2</filename> on 64-bit systems. A sure-fire way to determine the name of the dynamic linker is to inspect a random binary from the host system by running: <userinput>readelf -l &lt;name of binary&gt; | grep interpreter</userinput> and noting the output. The authoritative reference covering all platforms is in <ulink url='https://sourceware.org/glibc/wiki/ABIList'>a Glibc wiki page</ulink>.

Faites également attention au nom de l'éditeur de liens dynamiques de la plateforme, souvent appelé chargeur dynamique (à ne pas confondre avec l'éditeur de liens standard <command>ld</command> qui fait partie de binutils). Le chargeur dynamique fourni par glibc trouve et charge les bibliothèques partagées nécessaires à l’exécution d’un programme, prépare le programme, puis l'exécute.Le nom du chargeur dynamique pour une machine Intel 32&nbsp;bits sera <filename class="libraryfile">ld-linux.so.2</filename> (<filename class="libraryfile">ld-linux-x86-64.so.2</filename> pour les systèmes 64&nbsp;bits). Pour déterminer le nom du chargeur dynamique, inspectez un binaire au hasard sur le système hôte en exécutant&nbsp;: <userinput>readelf -l &lt;nom du binaire&gt; | grep interpreter</userinput> et récupérez le résultat. La référence officielle qui couvre toutes les plateformes se trouve sur <ulink url='https://sourceware.org/glibc/wiki/ABIList'>une page wiki de Glibc</ulink>.