[ILDP-LFS] chapter 05 - toolchaintechnotes.xml

[Sebastiano Gazzola]

-------------- parte successiva --------------
--- originale/chapter05/toolchaintechnotes.xml	2004-06-17 14:08:30.250000000 +0200
+++ revisionata/chapter05/toolchaintechnotes.xml	2004-10-20 19:41:59.078125000 +0200
@@ -8,14 +8,14 @@
 <?dbhtml filename="toolchaintechnotes.html"?>
 
 <para>Questa sezione intende spiegare alcuni dettagli logici e tecnici dietro
-al metodo generale di costruzaione. Non è essenziale comprendere tutto ora. 
-La maggior parte apparirà chiara dopo aver effettuato una vera costruzione.
+al metodo generale di compilazione. Non è essenziale comprendere tutto ora. 
+La maggior parte apparirà chiara dopo aver effettuato una vera compilazione.
 Si potrà poi ritornare qui liberamente in ogni istante.</para>
 
 <para>L'obiettivo principale del <xref linkend="chapter-temporary-tools"/> è 
 mettere a disposizione un ambiente temporaneo integro, nel quale si possa effettuare 
 il chroot, e dal quale si possa produrre nel <xref linkend="chapter-building-system"/> 
-una costruzione pulita e libera da problemi del sistema LFS finale. Lungo la strada, 
+una compilazione pulita e libera da problemi del sistema LFS finale. Lungo la strada, 
 si cercherà di allontanarsi il più possibile dal sistema ospite, e, nel fare ciò,
 di costruire una toolchain autocontenuta ed autoospitata. Occorre rimarcare che il 
 processo di costruzione è stato progettato in modo da minimizzare il rischio per i 
@@ -37,7 +37,7 @@
 indicato spesso come <emphasis>dynamic loader</emphasis>, che non va confuso con 
 il linker standard <emphasis>ld</emphasis>, il quale fa parte di Binutils. Il 
 linker dinamico è fornito con Glibc e ha il compito di trovare e caricare le 
-librerie condivise necessarie ad un programma, preparando ilh progamma per l'esecuzione 
+librerie condivise necessarie ad un programma, preparando il progamma per l'esecuzione 
 e poi lanciandolo. Nella maggior parte dei casi, il linker dinamico sarà 
 <emphasis>ld-linux.so.2</emphasis>. Su piattaforme meno diffuse il nome potrebbe
 essere <emphasis>ld.so.1</emphasis>, mentre le nuove piattaforme a 64 bit potrebbero
@@ -56,34 +56,34 @@
 <itemizedlist>
 <listitem><para>Simile al principio del cross compiling, dove gli strumenti 
 installati con lo stesso prefisso lavorano in cooperazione utilizzando un po'
-di <quote>magia</quote> GNU..</para></listitem>
+di <quote>magia</quote> GNU.</para></listitem>
 
 <listitem><para>Attenta manipolazione del percorso standard di ricerca delle 
 librerie da parte del linker, per assicurarsi che i programmi siano collegati 
 soltanto alle librerie desiderate.</para></listitem>
 
 <listitem><para>Attenta manipolazione del file <emphasis>specs</emphasis> di 
-<command>gcc</command>, per imporra al compilatore il linker dinamico da usare.</para></listitem>
+<command>gcc</command>, per imporre al compilatore il linker dinamico da usare.</para></listitem>
 </itemizedlist>
 
 <para>Binutils è installato per primo, perché sia GCC, sia Glibc eseguono
 vari test sulle caratteristiche dell'assembler e del linker durante l'esecuzione dei
 rispettivi <command>./configure</command>, per stabilire quali funzionalità del
 software abilitare o disabilitare. Ciò è più importante di quanto si possa credere.
-Un GCC o un Glibc mal configurato puiò portare ad una toolchain interrotta in modo
-sottile, dove l'impatto di tale interruzione potrebbe non apparire fin quasi al 
+Un GCC o un Glibc mal configurato può portare ad una toolchain interrotta in modo
+subdolo, dove l'impatto di tale interruzione potrebbe non apparire fin quasi al 
 completamento della costruzione di un'intera distribuzione. Fortunatamente, un
 insuccesso delle test suite normalmente segnalerà la cosa prima che si sia sprecato
 troppo tempo.</para>
 
-<para>Binitils installa i suoi assembler e linker in due directories: 
+<para>Binutils installa i suoi assembler e linker in due directories: 
 <filename class="directory">/tools/bin</filename> e
 <filename class="directory">/tools/$TARGET_TRIPLET/bin</filename>. In realtà, 
 gli strumenti in una directory sono collegati agli altri. Un aspetto importante del 
 linker è il suo ordine di ricerca delle librerie. È possibile ottenere informazioni 
 più dettagliate usando <command>ld</command>  con l'opzione <emphasis>--verbose</emphasis>. 
 Per esempio, <command>ld --verbose | grep SEARCH</command> mostrerà i percorsi 
-e la sequenza di ricerca in uso. E' possiile vedere quali file vengono effettivamente
+e la sequenza di ricerca in uso. È possibile vedere quali file vengono effettivamente
 linkati da <command>ld</command> compilando un programma vuoto e passando l'opzione 
 <emphasis>--verbose</emphasis> al linker. Per esempio, il comando 
 <command>gcc dummy.c -Wl,--verbose 2&gt;&amp;1 | grep succeeded</command> mostrerà 
@@ -102,22 +102,22 @@
 <command>gcc</command> non sono necessariamente usati i medesimi percorsi. Si potrà 
 individuare il linker usato di norma da <command>gcc</command> eseguendo:
 <command>gcc -print-prog-name=ld</command>.
-Informazioni dettagliate possono essere ottenutr da <command>gcc</command> passando
+Informazioni dettagliate possono essere ottenute da <command>gcc</command> passando
 l'argomento <emphasis>-v</emphasis> nella compilazione di un programma vuoto. Per
 esempio: <command>gcc -v dummy.c</command> mostrerà informazioni dettagliate sul
 preprocessore e sulle fasi di compilazione e assemblaggio, compresi i percorsi
 e l'ordine di ricerca degli include da parte di <command>gcc</command>.</para>
  
 <para>Il terzo pacchetto installato è Glibc. Gli elementi di maggiore importanza 
-per la costruzione di Glibc sono il compilatore, i binary tools e gli header del 
+per la costruzione di Glibc sono il compilatore, i binary tool e gli header del 
 kernel. Generalmente, il compilatore non è un problema, dal momento che Glibc 
 userà sempre il <command>gcc</command> trovato in una delle directory in $PATH. 
-I binary tools e gli headers del kernel potrebbero essere più complicati. 
-Pertanto, senza prendere rischi, si useranno le opzioni di configurazione 
+I binary tool e gli header del kernel potrebbero essere più complicati. 
+Pertanto, senza correre rischi, si useranno le opzioni di configurazione 
 per imporre le scelte corrette. Dopo l'esecuzione di <command>./configure</command>
 si potrà controllare il contenuto del file <filename>config.make</filename> 
 nella directory <filename class="directory">glibc-build</filename>
-glibc-build per i dettagli significativi. Si noteranno alcuni elementi
+per i dettagli significativi. Si noteranno alcuni elementi
 importanti, come l'uso di  <emphasis>CC="gcc -B/tools/bin/"</emphasis> per 
 determinare i binary tools da utilizzare, ed anche l'uso dei flag 
 <emphasis>-nostdinc</emphasis> e <emphasis>-isystem</emphasis> per controllare 
@@ -126,18 +126,18 @@
 autosufficiente per quanto riguarda il proprio meccanismo di costruzione e 
 generalmente non si affida ai default della toolchain.</para>
 
-<para>Dopo l'installazione di Glibc, verrà fatto qualche aggustamento per 
+<para>Dopo l'installazione di Glibc, verrà fatto qualche aggiustamento per 
 assicurarsi che la ricerca ed il link vengano effettuati solo all'interno 
-del prefisso <filename>/tools</filename>. Verrà instato un <command>ld</command>
+del prefisso <filename>/tools</filename>. Verrà installato un <command>ld</command>
 ad hoc, che ha codificato un percorso di ricerca limitato a
 <filename class="directory">/tools/lib</filename>. Poi si modificherà il file 
 specs  di <command>gcc</command> perchè si indirizzi al nuovo linker dinamico 
 <filename class="directory">/tools/lib</filename>. Quest'ultimo passo è 
 <emphasis>vitale</emphasis> per l'intero processo. Come già scritto, il percorso 
-predefinito del linker dinamico espressamente codificato in ogni eseguibile ELF
-condiviso. Esso può essere sipezionatp eseguendo: 
+predefinito del linker dinamico è espressamente codificato in ogni eseguibile ELF
+condiviso. Esso può essere ispezionato eseguendo: 
 <command>readelf -l &lt;name of binary&gt; | grep interpreter</command>.
-Con la modifica il file specs di <command>gcc</command>, ci si assicura che ogni 
+Con la modifica del file specs di <command>gcc</command>, ci si assicura che ogni 
 programma compilato da qui alla fine del capitolo utilizzi il nuovo linker dinamico
 in <filename class="directory">/tools/lib</filename>.</para>
 
@@ -150,13 +150,13 @@
 
 <para>Durante il secondo passaggio di Binutils, si potrà usare l'opzione di configure 
 <emphasis>--with-lib-path</emphasis> per regolare il percorso di ricerca delle librerie 
-da parte <command>ld</command>. Da questo punto in avanti, la toolchain di base è 
+da parte di <command>ld</command>. Da questo punto in avanti, la toolchain di base è 
 autocontenuta ed autoospitata. Gli altri pacchetti del 
 <xref linkend="chapter-temporary-tools"/> saranno costruiti con in nuovo Glibc 
 in <filename class="directory">/tools</filename>, e tutto andrà bene.</para>
 
 <para>Nel passare all'ambiente chroot nel <xref linkend="chapter-building-system"/>, 
-il primo paccetto importante installato sarà Glibc, per via della sua natura 
+il primo pacchetto importante installato sarà Glibc, per via della sua natura 
 autosufficiente già menzionata. Una volta che installato questo Glibc 
 in <filename class="directory">/usr</filename> si effettuerà un rapido 
 cambiamento dei parametri di default della toolchain, per poi procedere alla 
@@ -196,7 +196,7 @@
 <para>Se il link dinamico offre tanti vantaggi, perche invece si effettua il 
 link statico dei primi due pacchetti del capitolo? Le ragioni sono di tre tipi: 
 storico, didattico e tecnico. Storico, perché le prime versioni di LFS 
-effettuavano il link statico tutti i programmi di questo capitolo. Didattico, 
+effettuavano il link statico in tutti i programmi di questo capitolo. Didattico, 
 perché è utile conoscere la differenza. Tecnica, perché in questo modo si guadagna
 un fattore di indipendeza dal sistema ospite, il che significa che questi programmi 
 potranno essere usati indipendentemente da esso. Vale comunque la pena di segnalare