Subversion Repositories svn LFS-FR

Rev

Rev 1342 | Blame | Compare with Previous | Last modification | View Log | RSS feed

<?xml version="1.0" encoding="ISO-8859-1"?>
<!DOCTYPE sect1 PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
 "http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd" [
 <!ENTITY % general-entities SYSTEM "../general.ent">
  %general-entities;
]>

<sect1 id="ch-tools-toolchaintechnotes">
  <?dbhtml filename="toolchaintechnotes.html"?>

  <title>Notes techniques sur la chaîne d'outils</title>

  <para>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.</para>

  <para>Le but global du <xref linkend="chapter-temporary-tools"/> 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
  <command>chroot</command>, 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.</para>

  <important>
 
       <para>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    
       <command>config.guess</command> venant avec le source pour un grand
       nombre de paquets. Déballez les sources de Binutils, lancez le
       script <userinput>./config.guess</userinput> et notez la sortie.
       Par exemple, pour un processeur Intel 32 bits moderne, la sortie
       sera du type <emphasis>i686-pc-linux-gnu</emphasis>.</para>
   
    <para>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 <command>ld</command> 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 <filename class="libraryfile">ld-linux.so.2</filename>.
    Une façon sûre de déterminer le nom de l'éditeur de liens dynamiques est de
    chercher dans le répertoire
    <filename class="directory">/lib</filename> 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&nbsp;:

    <userinput>readelf -l &lt;nom du binaire&gt; | grep interpreter</userinput>

    et de noter le résultat. La référence faisant autorité couvrant toutes les
    plateformes est dans le fichier <filename>shlib-versions</filename> à la
    racine du répertoire des sources de Glibc.</para>
  </important>

  <para>Quelques points techniques sur la façon dont fonctionne la
  méthode de construction

  <xref linkend="chapter-temporary-tools"/>&nbsp;:</para>

  <itemizedlist>
    <listitem>
      <para>Un léger ajustement du nom de la plateforme de travail,
      en modifiant le champ &quot;vendor&quot; de la triplette cible via la variable
      <envar>LFS_TGT</envar>, 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.</para>
    </listitem>
    <listitem>
      <para>Les bibliothèques temporaires sont compilées de manière croisée.
      Puisqu'un compilateur croisé, par nature, ne peut pas se baser sur quoique ce soit issu de son système hôte,
      cette méthode supprime toute possibilité de contamination du szstème cible
      en diminuant les chances des en-têtes ou des bibliothèques du système hôte
      d'être incluses dans les nouveaux outils. La compilation croisée offre
      aussi la possibilité de construire à la fois des bibliothèques 32 et 64 bits
      sur du matériel gérant le 64 bits.</para>
    </listitem>
    <listitem>
      <para>Une manipulation attentionnée du fichier <filename>specs</filename>
      de <command>gcc</command> indique au compilateur
      l'éditeur de liens dynamique cible à utiliser.</para>
    </listitem>
  </itemizedlist>

  <para>Binutils est tout d'abord installé parce que les exécutions de
  Glibc et GCC par <command>configure</command> 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é.</para>

  <para>Binutils installe son assembleur et son éditeur de liens à deux
  endroits, <filename class="directory">/tools/bin</filename> et
  <filename class="directory">/tools/$LFS_TGT/bin</filename>. 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 <command>ld</command> en lui passant le commutateur
  <parameter>--verbose</parameter>. Par exemple, un

  <userinput>ld --verbose | grep SEARCH</userinput> illustrera les
  chemins de recherche réels et leur ordre. Il montre quels fichiers
  sont liés par <command>ld</command> en compilant un programme de test
  et en passant le commutateur <parameter>--verbose</parameter> à
  l'éditeur de liens. Par exemple,

  <userinput>gcc dummy.c -Wl,--verbose 2&gt;&amp;1 | grep
  succeeded</userinput> affichera tous les fichiers ouverts avec succès
  lors de l'édition des liens.</para>

  <para>Le prochain paquetage installé est GCC. Un exemple de ce qui
  peut être vu pendant son exécution de <command>configure</command>
  est&nbsp;:</para>

<screen><computeroutput>checking what assembler to use... /tools/i686-lfs-linux-gnu/bin/as
checking what linker to use... /tools/i686-lfs-linux-gnu/bin/ld</computeroutput></screen>

  <para>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

  <command>gcc</command>, les mêmes chemins de recherche ne sont pas
  forcément utilisés. Pour trouver quel éditeur de liens standard
  <command>gcc</command> utilisera, lancez&nbsp;:

  <userinput>gcc  -print-prog-name=ld</userinput></para>

  <para>Vous  pouvez obtenir des informations détaillées à partir de
  <command>gcc</command> en lui fournissant l'option en ligne de
  commande <parameter>-v</parameter> lors de la compilation d'un
  programme de tests. Par exemple, <userinput>gcc -v dummy.c</userinput>
  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
  <command>gcc</command> et leur ordre.</para>

  <para>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 <parameter>--host</parameter> passé à
  son script configure, par exemple, dans notre cas,
  <command>i686-lfs-linux-gnu-gcc</command>.
  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
  <command>configure</command>, vérifiez le contenu du fichier <filename>config.make</filename>
  dans le répertoire <filename class="directory">glibc-build</filename> pour tous les détails importants. Notez
  l'utilisation de
  <parameter>CC="i686-lfs-gnu-gcc"</parameter> pour contrôler le outils
  binaires utilisés, et l'utilisation des commutateurs
  <parameter>-nostdinc</parameter> et <parameter>-isystem</parameter>
  pour contrôler le chemin de recherche des en-têtes du compilateur. Ces
  éléments soulignent un aspect important du paquetage glibc&mdash;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.</para>

  <para>Après l'installation de Glibc, modifiez le
  fichier specs de <command>gcc</command>  pour pointer vers le nouvel éditeur de
  liens dynamique dans
  <filename class="directory">/tools/lib</filename>. 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 <filename class="directory">/tools</filename>.
  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&nbsp;:

   <userinput>readelf -l &lt;nom du binaire&gt; | grep interpreter</userinput>.
   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
  <filename class="directory">/tools/lib</filename>.</para>

  <para>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

  <filename class="directory">/lib</filename> 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

  <filename  class="directory">/lib</filename> du système hôte intégré
  en eux, ce qui empêchera le but de s'éloigner de l'hôte.</para>

  <para>Lors de la seconde passe de Binutils, nous sommes capable  
d'utiliser l'option <parameter>--with-lib-path</parameter> de  
configure pour contrôler le chemin de recherche des bibliothèques de
<command>ld</command>. À partir de là, la chaîne d'outils principal est
contenu en lui-même. Le reste des paquetages de <xref  
linkend="chapter-temporary-tools"/> se construit à partir de la nouvelle
Glibc dans

<filename class="directory">/tools</filename>.</para>

  <para>Avant d'entrer dans l'environnement chroot dans <xref
 linkend="chapter-building-system"/>, 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  <filename
 class="directory">/usr</filename>, 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.</para>

  <!-- FIXME: Removed as part of the fix for bug 1061 - we no longer build pass1
     packages statically, therefore this explanation isn't required

 <sect2> <title>Notes sur l'édition de liens statiques</title>

 <para>En dehors de leur tâches spécifiques, la plupart des programmes
 doivent réaliser un grand nombre d'opérations habituelles, voire
 triviales. Elles incluent l'allocation de mémoire, la recherche dans
 des répertoire, la lecture et l'écriture de fichiers, la gestion des
 chaînes de caractères, la reconnaissance de modèles, l'arithmétique et
 d'autres tâches. Au lieu d'obliger chaque programme à réinventer la
 roue, le système GNU fournit toutes ces fonctions de base dans des
 bibliothèques toutes prêtes. La bibliothèque majeure sur un système
 Linux est Glibc.</para>

 <para>Il existe deux façons de lier les fonctions d'une bibliothèque
 dans un programme qui les utilise&mdash;statiquement ou dynamiquement.
 Quand un programme est lié statiquement, le code des fonctions
 utilisées est inclus dans l'exécutable, donnant un gros programme.
 Quand un programme est lié dynamiquement, il inclut une référence à
 l'éditeur de liens, le nom de la bibliothèque et le nom de la
 fonction, aboutissant à un exécutable bien plus petit. Une troisième
 option est d'utiliser l'interface de programmation de l'éditeur de
 liens (voir la page man <filename>dlopen(3)</filename> pour plus
 d'informations).</para>

 <para>L'édition de liens dynamiques est le comportement par défaut sur
 Linux et a trois avantages majeurs sur l'édition de liens statiques.
 Tout d'abord, seule une copie du code exécutable de la bibliothèque
 est nécessaire sur le disque dur, à la place de plusieurs copies du
 même code inclus dans plusieurs programmes, sauvegardant ainsi de
 l'espace disque. Deuxièmement, quand plusieurs programmes utilisent la
 même fonction de bibliothèque en même temps, seule une copie du code
 de la fonction est requis en mémoire, sauvegardant ainsi de la mémoire
 vive. Troisièmement, quand une fonction d'une bibliothèque est
 corrigée ou améliorée, seule la bibliothèque doit être recompilée au
 lieu de recompiler tous les programmes utilisant ladite
 fonction.</para>

 <para>Si l'édition de liens dynamiques a plusieurs avantages, alors  
pourquoi   utilisons-nous l'édition statique pour les deux premiers
paquetages   dans ce  chapitre&nbsp;? Il y a trois raisons &mdash;
historique, éducative et technique. La raison historique est que les
versions antérieures de LFS liaient statiquement tous les programmes de
ce chapitre. Sur le plan éducatif, connaître les différences entre
statique et dynamique est utile. Le bénéfice technique est un élément
gagné pour l'indépendance sur le système hôte, signifiant que les
programmes peuvent être utilisés indépendamment du système hôte.
Néanmoins, il est bon de noter qu'une construction réussie de LFS peut
toujours se faire quand les deux premiers paquetages de LFS sont
construits dynamiquement.</para>

 </sect2>-->

</sect1>