Questa sezione prova a spiegare alcuni dei dettagli tecnici e logici dietro al metodo di costruzione complessivo. Non è importante che qui si comprenda ogni cosa immediatamente. Molto di questo avrà senso quando si sarà realizzata una compilazione. Questa sezione può essere ripresa in ogni momento durante il procedimento

Lo scopo complessivo del Capitolo 5 è di fornire un ambiente provvisorio in cui si possa accedere con chroot, e dal quale si possa produrre una costruzione pulita e priva di problemi del sistema LFS, obiettivo del Capitolo 6. Lungo la strada, ci si separa il più possibile dal sistema host, e nel farlo si costruisce una toolchain auto-contenuta che si auto-ospita. Bisogna notare che il processo di costruzione è stato pensato per minimizzare il rischio per i lettori nuovi e fornire un minimo valore didattico nello stesso tempo. In altre parole, potrebbero essere utilizzate tecniche più avanzate per costruire il sistema.

Alcuni punti tecnici su come funziona il metodo di costruzione del Capitolo 5:

Le binutils sono installate per prime perché il file ./configure eseguito sia da GCC che da Glibc effettua vari tipi di test sull'assemblatore e il linker per determinare quali caratteristiche del software abilitare e disabilitare. Ciò è molto più importante di quanto uno possa pensare inizialmente. Una configurazione scorretta di GCC o Glibc può portare a una toolchain corrotta, dove l'impatto di una tale corruzione potrebbe non evidenziarsi fin quasi al termine della costruzione dell'intera distribuzione. Grazie al cielo, un fallimento di una suite di test normalmente ci avvisa prima di aver perso troppo tempo.

Le Binutils installano il loro assemblatore e linker in due locazioni, /tools/bin e /tools/$TARGET_TRIPLET/bin. I tool in ogni locazione sono collegati stabilmente all'altra. Un aspetto importante del linker è il suo ordine di ricerca della libreria. Informazioni dettagliate si possono ottenere da ld passandogli il flag --verbose. Ad esempio, un ld --verbose | grep SEARCH illustrerà i percorsi di ricerca correnti e il loro ordine. Esso mostra quali file sono linkati da ld compilando un programma dummy e passando lo switch --verbose al linker. Ad esempio, gcc dummy.c -Wl,--verbose 2>&1 | grep succeeded mostrerà tutti i file aperti con successo durante la fase di link.

Il prossimo pacchetto installato è GCC. Un esempio di ciò che si può vedere durante la sua esecuzione di ./configure è:

checking what assembler to use... 
        /tools/i686-pc-linux-gnu/bin/as
checking what linker to use... /tools/i686-pc-linux-gnu/bin/ld

Ciò è importante per le ragioni sopra menzionate. Dimostra anche che lo script di configurazione di GCC non cerca le directory del PATH per trovare quali tool usare. Tuttavia, durante le attuali operazioni dello stesso gcc, non vengono necessariamente usati gli stessi percorsi di ricerca. Per scoprire quale linker standard sarà usato da gcc eseguire: gcc -print-prog-name=ld.

Informazioni dettagliate possono essere ottenute da gcc passandogli l'opzione da linea di comando -v quando compila un programma dummy. Ad esempio, gcc -v dummy.c mostrerà informazioni dettagliate riguardanti preprocessore, compilazione, e fase di assemblaggio, includendo i percorsi gcc di ricerca e il loro ordine.

Il pacchetto installato successivamente è Glibc. Le considerazioni più importanti per costruire Glibc riguardano il compilatore, i tool binari e gli header del kernel. Il compilatore normalmente non è un problema perché Glibc userà sempre il gcc trovato in una directory del PATH. I tool binari e gli header del kernel possono essere un po' più complicati. Pertanto non si prendano rischi e si utilizzino gli switch di configurazione disponibili per forzare le selezioni corrette. Dopo 'esecuzione di ./configure, verificare i contenuti del file config.make nella directory glibc-build per tutti i dettagli importanti. Notare l'uso di CC="gcc -B/tools/bin/" per controllare quali tool binari sono usati e l'uso dei flag -nostdinc e -isystem per controllare il percorso di ricerca dell'include del compilatore. Queste cose evidenziano un importante aspetto del pacchetto Glibc: è molto autosufficiente nel suo motore di costruzione e generalmente non fa riferimento ai default della toolchain.

Dopo l'installazione di Glibc, apportare alcuni aggiustamenti per garantire che ricerca e collegamento prendano posto solo nel prefisso /tools. Installare un ld aggiustato, che ha un percorso di ricerca incluso in esso limitato a /tools/lib. Quindi correggere il file specs di gcc per farlo puntare al nuovo linker dinamico in /tools/lib. Questo ultimo passo è vitale per l'intero processo. Come citato in precedenza, un percorso fisso verso un linker dinamico è incluso in ogni eseguibile Executable and Link Format (ELF) condiviso. Ciò può essere controllato eseguendo: readelf -l <nome del binario> | grep interpreter. Correggendo il file specs di gcc si garantisce che ogni programma compilato da qui alla fine di questo capitolo usi il nuovo linker dinamico in /tools/lib.

La necessità di usare il nuovo linker dinamico è anche la ragione per cui la patch Specs è applicata per il secondo passo di GCC. Non fare questo significa far sì che gli stessi programmi GCC abbiano il nome del linker dinamico dalla directory del sistema host /lib incluso in essi, cosa che vanificherebbe l'oiettivo di allontanarci dall'host.

Durante il secondo passo di Binutils, si può utilizzare lo switch di configurazione --with-lib-path per controllare il percorso di ricerca delle librerie di ld. Da questo punto in poi, la toolchain principale è auto-contenuta e si auto-ospita. I rimanenti pacchetti del Capitolo 5 si costruiscono tutti con la nuova Glibc in /tools.

Una volta entrati nell'ambiente chroot nel Capitolo 6, il primo grosso pacchetto che si installa è Glibc, per via della sua natura auto-sufficiente cui si è accennato prima. Una volta installato Glibc in /usr, si realizza un rapido cambio dei default della toolchain, e quindi si procede alla vera costruzione del resto del sistema LFS.