[lfs-fr] r1065 - trunk/clfs/final-system/multilib

Jean-Philippe MENGUAL jmengual at linuxfromscratch.org
Mar 22 Déc 16:16:44 PST 2009


Bonsoir,

Je n'oublie pas le travail et y suis régulièrement, même si moins que ce
que je voudrais. Je répercute les correc de la révision là.

Ca m'inspire une nouvelle clarification méthodologique tirée de
l'expérience. J'essaie de simplifier:

S'agissant des 1ers jets de traduction (astuces ou traduction de livre),
j'aimerais qu'ils soient sous forme de patch (pour le livre) ou de
fichier txt entièrement francisés (les astuces), mais en Pièce jointe.
Etant un texte, le contenu du patch apparaîtra de toute façon dans le
corps à la fin du message, mais s'il est en PJ je peux l'exploiter plus
vite.

Pour la correction des premiers jets, ok pour la faire direct dans le
corps du message. Mais alors, j'aimerais que le relecteur ne fasse
apparaître que les lignes du fichiers qu'il entend corriger.

Exemple:
> Modified: trunk/clfs/final-system/multilib/libtool-n32.xml
> ===================================================================
> --- trunk/clfs/final-system/multilib/libtool-n32.xml 2009-12-13
22:17:44 UTC (rev 1064)
> +++ trunk/clfs/final-system/multilib/libtool-n32.xml 2009-12-14
22:03:44 UTC (rev 1065)
> @@ -8,7 +8,7 @@
> <sect1 id="ch-system-libtool-n32" role="wrap">
> <?dbhtml filename="libtool-n32.html"?>
> 
> - <title>Libtool-&libtool-version; N32 Libraries</title>
> + <title>Libtool-&libtool-version; N32</title>
bibliothèques
> 
> <indexterm zone="ch-system-libtool-n32">
> <primary sortas="a-Libtool">Libtool</primary>
> @@ -43,10 +43,10 @@
> href="../common/libtool.xml"
> xpointer="xpointer(//*[@os='d'])"/>
> 
> - <para os="e">To test the results, identify the correct emulation,
then issue:
> - <userinput>make LDEMULATION=[emulation] check</userinput>. The
correct
> - emulation will be elf32btsmipn32 for a big-endian machine and
elf32ltsmipn32
> - for a little-endian machine.</para>
> + <para os="e">Pour tester les résultats, identifiez la bonne
émulation puis faites :
> + <userinput>make LDEMULATION=[émulation] check</userinput>. La bonne
émulation est 
> + elf32btsmipn32 pour une machine big-endian etm elf32ltsmipn32 pour
une machine 
s/etm/et/

> Modified: trunk/clfs/final-system/multilib/libtool.xml
> ===================================================================
> --- trunk/clfs/final-system/multilib/libtool.xml 2009-12-13 22:17:44
UTC (rev 1064)
> +++ trunk/clfs/final-system/multilib/libtool.xml 2009-12-14 22:03:44
UTC (rev 1065)
> @@ -26,9 +26,9 @@
> <sect2 role="installation">
> <title>Installation de Libtool</title>
> 
> - <para os="a1">The following <filename>config.cache</filename> entry
> - overrides the default search path, which does not take
> - multilib into account:</para>
> + <para os="a1">Le fichier <filename>config.cache</filename> suivant
permet 
> + de forcer le chemin de recherche par défaut à prendre en compte 
...défaut _pour_ prendre...

> @@ -67,18 +67,17 @@
> href="../ppc64/libtool.xml"
> xpointer="xpointer(//*[@os='c2'])"/> -->
> <listitem os="c2">
> - <para>Libtool tends to do the wrong thing when building for
multilib,
> - at least on the non-default size(s) of architecture. The causes of
> - these errors are not well understood and they can appear, or
disappear,
> - as a result of apparently innocuous other changes in the build. In
> - this version of the book, one of the tests (pdemo-make) fails to
link
> - because it tries to link the 32-bit objects against 64-bit system
> - libraries. This option enables the test to succeed without impacting
> - the other tests (compare the common alternative fixes of
> - <literal>LD="gcc ${BUILD32}"</literal> which causes far fewer tests
> - to be executed, and configuring with
> - <literal>LDFLAGS='-L/lib -L/usr/lib'</literal> which in this case
> - causes other tests to fail.)</para>
> + <para>Libtool a tendance à se comporter d efaçon inattendue en
environnement multilib, 
_de façon_...

> + du moins sur des architectures autres que celle par défaut. On ne
saisit pas tout à fait 
> + les causes de ces erreurs car elles peuvent apparaître ou
disparaître bon gré mal gré, 
> + même lors de changements normalement inoffensifs au bon déroulement
de la compilation. 
supprimer "bon gré mal gré", ça ne parrait pas nécessaire.

> + Dans cette version du livre, l'un des tests, pdemo-make, ne se lie
pas correctement 
> + car il cherche à lier les objets 32 bits aux bibliothèques 64 bits
du système. 
> + Cette option permet à ce test de réussir sans impacter les autres
tests (comparé aux méthodes 
compare_r_

> + de correction plus traditionnelles comme spécifier 
> + <literal>LD="gcc ${BUILD32}"</literal>, ce qui empêche l'exécution
de nombreux test ou bien
> + configurer avec <literal>LDFLAGS='-L/lib -L/usr/lib'</literal>, ce
qui dans ce cas fait échouer 
> + d'autres tests).</para>
> </listitem>
> </varlistentry>
> 
> @@ -92,8 +91,9 @@
> href="../common/libtool.xml"
> xpointer="xpointer(//*[@os='g'])"/>
> 
> - <para os="m1">Prepare <filename>libtool</filename> to be wrapped by
> - the multiarch wrapper. Libtool by itself is not multilib
aware:</para>
> + <para os="m1">Préparez <filename>libtool</filename> à êtere emballé
dans le
_être_

> + script d'emballage multi-architecture (« multiarch-wrapper »).
Libtool seul 
> + ne supporte pas l'environnement multilib :</para>

Devrait devenir:
> Modified: trunk/clfs/final-system/multilib/libtool-n32.xml
> ===================================================================
> --- trunk/clfs/final-system/multilib/libtool-n32.xml 2009-12-13
22:17:44 UTC (rev 1064)
> +++ trunk/clfs/final-system/multilib/libtool-n32.xml 2009-12-14
22:03:44 UTC (rev 1065)
> @@ -8,7 +8,7 @@
> <sect1 id="ch-system-libtool-n32" role="wrap">
> <?dbhtml filename="libtool-n32.html"?>
> 
> - <title>Libtool-&libtool-version; N32 Libraries</title>
> + <title>Libtool-&libtool-version; N32</title>
bibliothèques
> 
> - <para os="e">To test the results, identify the correct emulation,
then issue:
> - <userinput>make LDEMULATION=[emulation] check</userinput>. The
correct
> - emulation will be elf32btsmipn32 for a big-endian machine and
elf32ltsmipn32
> - for a little-endian machine.</para>
> + <para os="e">Pour tester les résultats, identifiez la bonne
émulation puis faites :
> + <userinput>make LDEMULATION=[émulation] check</userinput>. La bonne
émulation est 
> + elf32btsmipn32 pour une machine big-endian etm elf32ltsmipn32 pour
une machine 
s/etm/et/

> Modified: trunk/clfs/final-system/multilib/libtool.xml
> ===================================================================

> - <para os="a1">The following <filename>config.cache</filename> entry
> - overrides the default search path, which does not take
> - multilib into account:</para>
> + <para os="a1">Le fichier <filename>config.cache</filename> suivant
permet 
> + de forcer le chemin de recherche par défaut à prendre en compte 
...défaut _pour_ prendre...


> - <para>Libtool tends to do the wrong thing when building for
multilib,
> + <para>Libtool a tendance à se comporter d efaçon inattendue en
environnement multilib, 
_de façon_...

> + du moins sur des architectures autres que celle par défaut. On ne
saisit pas tout à fait 
> + les causes de ces erreurs car elles peuvent apparaître ou
disparaître bon gré mal gré, 
> + même lors de changements normalement inoffensifs au bon déroulement
de la compilation. 
supprimer "bon gré mal gré", ça ne parrait pas nécessaire.

> +          Cette option permet à ce test de réussir sans impacter les
autres tests (comparé aux méthodes 
compare_r_

> - <para os="m1">Prepare <filename>libtool</filename> to be wrapped by
> - the multiarch wrapper. Libtool by itself is not multilib
aware:</para>
> + <para os="m1">Préparez <filename>libtool</filename> à êtere emballé
dans le
_être_

En clair, l'objectif et de ne garder que l'essentiel: la faute, la
correction, et si besoin le contexte (rare). Ca m'accélérera le
défilement du patch général contenant plusieurs fichiers.

N'hésitez pas si besoin de plus de précisions. Merci de votre
compréhension.

Bonne nuit à tous,


-  
       Jean-Philippe MENGUAL
       Vice-Président de l'association traduc.org 
       Coordinateur du projet Linux From Scratch



Le vendredi 18 décembre 2009 à 22:59 +0100, appzer0 a écrit :
> On 18/12/2009 17:16, appzer0 wrote:
> > Merci pour tout, je reprends la traduction dans son ensemble en
> > appliquant toutes les observations - je viens d'installer ma slackware64
> > suite à un changement de machine, ce qui explique ma non réactivité.
> >
> > appzer0
> >    
> Après corrections, voici ce que donne le contexte du multiarch wrapper 
> et sa désignation. On parle ici de renommer les bibliothèques en *-32 
> *-64 afin de le passer au programme maison de CLFS qui passera alors les 
> bons chemins de recherche selon le suffixe :
> 
> Libtool : « Préparez libtool à être pris en charge par le programme 
> enveloppe multi-architecture. »
> 
> multiarch_wrapper :
> « Création d'un programme enveloppe multi-architecture ( « Multiarch 
> Wrapper ») »
> 
> « Le programme enveloppe multi-architecture, ou « Multiarch Wrapper », 
> sert à
>      envelopper certains binaires contenant en dur les chemins vers 
> leurs bibliothèques ou bien qui
>      sont spécifiques à certaines architectures. »
> 
> Si vous êtes d'accord, il faudra alors s'en tenir à cette désignation. 
> J'ai terminé ma re-traduction de final-system/multilib - j'attends la 
> réponse du coordinateur pour réencoder en ISO ou pas. Merci à Emmanuel 
> pour son excellente  relecture.
> 
> appzer0




More information about the lfs-traducfr mailing list