Linux From Scratch - Versione 6.2

Capitolo 5. Costruzione di un sistema temporaneo

5.7. Regolazione della toolchain

Ora che le librerie C provvisorie sono state installate vogliamo che tutti gli strumenti compilati nel resto di questo capitolo siano linkati verso queste librerie. Per fare questo bisogna sistemare i file specs del linker e del compilatore.

Il linker, sistemato al termine del primo passo di Binutils, deve essere rinominato per essere propriamente rintracciato ed usato. Prima, salvare il linker originale, poi sostituirlo con il linker sistemato. Verrà creato anche un link al proprio omologo in /tools/$(gcc -dumpmachine)/bin: 

mv -v /tools/bin/{ld,ld-old}
mv -v /tools/$(gcc -dumpmachine)/bin/{ld,ld-old}
mv -v /tools/bin/{ld-new,ld}
ln -sv /tools/bin/ld /tools/$(gcc -dumpmachine)/bin/ld

D'ora in poi ogni cosa verrà linkata solo verso le librerie in /tools/lib.

Il prossimo lavoro è far puntare GCC al nuovo linker dinamico. Questo è ottenuto dal dump del file «specs» del GCC in una locazione dove GCC potrà accederci di default. Poi, una semplice sostituzione con sed modifica il linker dinamico che GCC utilizzerà: 

SPECFILE=`dirname $(gcc -print-libgcc-file-name)`/specs &&
gcc -dumpspecs > $SPECFILE &&
sed 's@^/lib/ld-linux.so.2@/tools&@g' $SPECFILE > tempspecfile &&
mv -vf tempspecfile $SPECFILE &&
unset SPECFILE

È importante che il comando sopra venga copiato e incollato per assicurare precisione. In alternativa il file specs può essere editato a mano. Questo lo si fa sostituendo ogni occorrenza di «/lib/ld-linux.so.2» con «/tools/lib/ld-linux.so.2»

Accertarsi di ispezionare visivamente il file specs per verificare che i cambiamenti voluti siano stati apportati.

[Importante]

Importante

Se si lavora su una piattaforma nella quale il nome del linker dinamico sia diverso da ld-linux.so.2, sostituire «ld-linux.so.2» con il nome del linker dinamico della propria piattaforma nel comando precedente. Fare riferimento alla Sezione 5.2, «Note tecniche sulla Toolchain,», se necessario.

Durante il processo di compilazione GCC esegue uno script (fixincludes) che esamina il sistema alla ricerca di file header che possono aver bisogno di essere corretti (per esempio, potrebbero contenere errori di sintassi), e installa le versioni corrette in una direttory include privata. C'è la possibilità che, come risultato di questo processo, alcuni file header del sistema host abbiano trovato una strada nella directory include privata di GCC. Dal momento che il resto di questo capitolo richiede solo gli header dal GCC e Glibc, che a questo punto sono entrambi stati installati, qualsiasi header «corretto» può essere rimosso in modo sicuro. Questo aiuta a evitare qualsiasi inquinamento negli header dell'host dell'ambiente di compilazione. Eseguire i seguenti comandi per rimuovere i file header nella directory include privata di GCC (a causa della lunghezza di questi comandi, si può trovare più comodo fare un copia e incolla, piuttosto che digitarli a mano): 

GCC_INCLUDEDIR=`dirname $(gcc -print-libgcc-file-name)`/include &&
find ${GCC_INCLUDEDIR}/* -maxdepth 0 -xtype d -exec rm -rvf '{}' \; &&
rm -vf `grep -l "DO NOT EDIT THIS FILE" ${GCC_INCLUDEDIR}/*` &&
unset GCC_INCLUDEDIR
[Attenzione]

Attenzione

A questo punto è imperativo fermarsi ed assicurarsi che le funzioni di base (compilazione e link) della nuova toolchain funzionino come previsto. Per eseguire una verifica di integrità eseguire i seguenti comandi: 

echo 'main(){}' > dummy.c
cc dummy.c
readelf -l a.out | grep ': /tools'

Se funziona tutto correttamente non ci devono essere errori, e l'output dell'ultimo comando sarà del tipo: 

[Requesting program interpreter: 
    /tools/lib/ld-linux.so.2]

Notare che /tools/lib appare come prefisso del linker dinamico.

Se l'output non appare come sopra o non c'è stato proprio output, allora c'è qualcosa di sbagliato. Investigare e ripercorrere i passi per trovare dove è il problema e correggerlo. Questo problema deve essere risolto prima di continuare. Dapprima eseguire di nuovo la verifica di integrità, usando gcc invece di cc. Se questo funziona, allora manca il symlink /tools/bin/cc. Rivedere la Sezione 5.4, «GCC-4.0.3 - Passo 1,» e installare il symlink. In seguito assicurarsi che il PATH sia corretto. Questo può essere verificato eseguendo echo $PATH e verificando che /tools/bin sia in cima alla lista. Se il PATH è sbagliato ciò può significare che non si è connessi come utente lfs o che qualcosa è andato storto nella precedente Sezione 4.4, «Configurazione dell'ambiente.» Un'altra possibilità è che qualcosa possa essere andato male con il file specs modificato in precedenza. In questo caso, rifare la modifica al file specs facendo attenzione a copiare e incollare i comandi.

Una volta che tutto va bene, togliere i file di test: 

rm -v dummy.c a.out
[Nota]

Nota

La costruzione di TCL nella prossima sezione servirà come verifica aggiuntiva che la toolchain è stata costruita correttamente. Se la costruzione di TCL fallisce, è un'indicazione che qualcosa è andato storto con l'installazione di Binutils, GCC, o Glibc, ma non con TCL in sè