Documentazione<Precedenti | Contenuti | Succ.>
5.2. Note tecniche sulla toolchain
Questa sezione spiega alcune delle motivazioni e dei dettagli tecnici alla base del metodo di costruzione generale. Non è essenziale capire immediatamente tutto in questa sezione. La maggior parte di queste informazioni sarà più chiara dopo aver eseguito una build effettiva. Questa sezione può essere consultata in qualsiasi momento durante il processo.
L'obiettivo generale del Capitolo 5 è produrre un'area temporanea che contenga una serie di strumenti noti che possono essere isolati dal sistema host. Usando chroot, i comandi nei capitoli rimanenti saranno contenuti in quell'ambiente, garantendo una build pulita e senza problemi del sistema LFS di destinazione. Il processo di compilazione è stato progettato per ridurre al minimo i rischi per i nuovi lettori e per fornire allo stesso tempo il valore più educativo.
Note:
Prima di continuare, tieni presente il nome della piattaforma di lavoro, spesso indicata come tripletta di destinazione. Un modo semplice per determinare il nome della tripletta di destinazione è eseguire il config.indovina script fornito con i sorgenti per molti pacchetti. Decomprimi i sorgenti di Binutils ed esegui lo script: ./config.indovina e annotare l'uscita. Ad esempio, per un processore Intel a 32 bit l'output sarà i686-pc-linux-gnu. Su un sistema a 64 bit sarà x86_64-pc-linux-gnu.
Tieni anche presente il nome del linker dinamico della piattaforma, spesso indicato come il caricatore dinamico (da non confondere con il linker standard ld che fa parte di Binutils). Il linker dinamico fornito da Glibc trova e carica le librerie condivise necessarie a un programma, prepara il programma per l'esecuzione e quindi lo esegue. Il nome del linker dinamico per una macchina Intel a 32 bit sarà ld-linux.so.2 (ld-linux-x86-64.so.2 per sistemi a 64 bit). Un modo sicuro per determinare il nome del linker dinamico consiste nell'ispezionare un binario casuale dal sistema host eseguendo: readelf -l | interprete grep e annotando l'uscita. Il riferimento autorevole che copre tutte le piattaforme è nel shlib-versioni file nella radice dell'albero dei sorgenti di Glibc.
Note:
Prima di continuare, tieni presente il nome della piattaforma di lavoro, spesso indicata come tripletta di destinazione. Un modo semplice per determinare il nome della tripletta di destinazione è eseguire il config.indovina script fornito con i sorgenti per molti pacchetti. Decomprimi i sorgenti di Binutils ed esegui lo script: ./config.indovina e annotare l'uscita. Ad esempio, per un processore Intel a 32 bit l'output sarà i686-pc-linux-gnu. Su un sistema a 64 bit sarà x86_64-pc-linux-gnu.
Tieni anche presente il nome del linker dinamico della piattaforma, spesso indicato come il caricatore dinamico (da non confondere con il linker standard ld che fa parte di Binutils). Il linker dinamico fornito da Glibc trova e carica le librerie condivise necessarie a un programma, prepara il programma per l'esecuzione e quindi lo esegue. Il nome del linker dinamico per una macchina Intel a 32 bit sarà ld-linux.so.2 (ld-linux-x86-64.so.2 per sistemi a 64 bit). Un modo sicuro per determinare il nome del linker dinamico consiste nell'ispezionare un binario casuale dal sistema host eseguendo: readelf -l | interprete grep e annotando l'uscita. Il riferimento autorevole che copre tutte le piattaforme è nel shlib-versioni file nella radice dell'albero dei sorgenti di Glibc.
Alcuni punti tecnici chiave su come funziona il metodo di compilazione del capitolo 5:
• Modificando leggermente il nome della piattaforma di lavoro, modificando la tripletta di target di campo "vendor" tramite il tasto LFS_TGT variabile, assicura che la prima build di Binutils e GCC produca un cross-linker e un cross-compiler compatibili. Invece di produrre binari per un'altra architettura, il cross-linker e il cross-compiler produrranno binari compatibili con l'hardware corrente.
• Le librerie temporanee vengono compilate in modo incrociato. Poiché un cross-compilatore per sua natura non può fare affidamento su nulla dal suo sistema host, questo metodo rimuove la potenziale contaminazione del sistema di destinazione riducendo la possibilità che le intestazioni o le librerie dell'host vengano incorporate nei nuovi strumenti. La cross-compilation consente anche la possibilità di creare librerie sia a 32 bit che a 64 bit su hardware a 64 bit.
• Un'attenta manipolazione del sorgente GCC indica al compilatore quale linker dinamico di destinazione verrà utilizzato.
Binutils viene installato per primo perché il configure le esecuzioni di GCC e Glibc eseguono vari test di funzionalità sull'assemblatore e sul linker per determinare quali funzionalità del software abilitare o disabilitare. Questo è più importante di quanto si possa pensare prima. Un GCC o Glibc configurato in modo errato può causare una toolchain leggermente danneggiata, in cui l'impatto di tale rottura potrebbe non manifestarsi fino alla fine della build di un'intera distribuzione. Un errore della suite di test di solito evidenzierà questo errore prima che venga eseguito troppo lavoro aggiuntivo.
Binutils installa il suo assemblatore e linker in due posizioni, /strumenti/bin ed /strumenti/$LFS_TGT/bin. Gli strumenti in una posizione sono strettamente collegati all'altra. Un aspetto importante del linker è il suo ordine di ricerca nella libreria. Informazioni dettagliate possono essere ottenute da ld passandolo il --verboso bandiera. Ad esempio, an ld --verbose | grep CERCA illustrerà i percorsi di ricerca correnti e il loro ordine. Mostra quali file sono collegati da ld compilando un programma fittizio e passando il --verboso passare al linker. Per esempio, gcc dummy.c -Wl,--verbose 2>&1
| grep riuscito mostrerà tutti i file aperti con successo durante il collegamento.
Il prossimo pacchetto installato è GCC. Un esempio di ciò che si può vedere durante la sua corsa configure è:
controllando quale assemblatore usare... /tools/i686-lfs-linux-gnu/bin/as controllando quale linker usare... /tools/i686-lfs-linux-gnu/bin/ld
controllando quale assemblatore usare... /tools/i686-lfs-linux-gnu/bin/as controllando quale linker usare... /tools/i686-lfs-linux-gnu/bin/ld
Questo è importante per i motivi sopra menzionati. Dimostra anche che lo script configure di GCC non cerca nelle directory PATH per trovare quali strumenti usare. Tuttavia, durante il funzionamento effettivo di gcc stesso, non vengono necessariamente utilizzati gli stessi percorsi di ricerca. Per scoprire quale linker standard gcc userà, eseguirà: gcc -print-nome-programma=ld.
Informazioni dettagliate possono essere ottenute da gcc passandolo il -v opzione della riga di comando durante la compilazione di un programma fittizio. Per esempio, gcc -v manichino.c mostrerà informazioni dettagliate sulle fasi di preprocessore, compilazione e assemblaggio, incluso gccinclude i percorsi di ricerca e il loro ordine.
Successivamente vengono installate le intestazioni API Linux disinfettate. Questi consentono alla libreria C standard (Glibc) di interfacciarsi con le funzionalità fornite dal kernel Linux.
Il prossimo pacchetto installato è Glibc. Le considerazioni più importanti per la compilazione di Glibc sono il compilatore, gli strumenti binari e gli header del kernel. Il compilatore generalmente non è un problema poiché Glibc utilizzerà sempre il compilatore relativo al --ospite parametro passato al suo script di configurazione; ad esempio nel nostro caso, il compilatore sarà i686-lfs-linux-gnu-gcc. Gli strumenti binari e gli header del kernel possono essere un po' più complicati. Pertanto, non correre rischi e utilizzare le opzioni di configurazione disponibili per applicare le selezioni corrette. Dopo la corsa di configure, controlla il contenuto del config.make file nella glibc build directory per tutti i dettagli importanti. Notare l'uso di CC="i686-lfs-gnu-gcc" per controllare quali strumenti binari vengono utilizzati e l'uso del -nostdin ed -isistema flag per controllare il percorso di ricerca di inclusione del compilatore. Questi elementi evidenziano un aspetto importante del pacchetto Glibc: è molto autosufficiente in termini di macchinari di costruzione e generalmente non si basa sui valori predefiniti della toolchain.
Durante il secondo passaggio di Binutils, siamo in grado di utilizzare il --with-lib-percorso configurare l'interruttore per controllare ldpercorso di ricerca della libreria.
Per il secondo passaggio di GCC, anche i suoi sorgenti devono essere modificati per dire a GCC di usare il nuovo linker dinamico. In caso contrario, i programmi GCC stessi avranno il nome del linker dinamico dal sistema host / lib directory incorporata al loro interno, che vanifica l'obiettivo di allontanarsi dall'host. Da questo punto in poi, la toolchain principale è autonoma e ospitata autonomamente. Il resto dei pacchetti del capitolo 5 è costruito contro la nuova Glibc in /utensili.
Entrando nell'ambiente chroot nel Capitolo 6, il primo pacchetto principale da installare è Glibc, a causa della sua natura autosufficiente menzionata sopra. Una volta installato questo Glibc in / usr, eseguiremo una rapida modifica delle impostazioni predefinite della toolchain, quindi procederemo alla creazione del resto del sistema LFS di destinazione.