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.
Dapprima installare il linker sistemato (ottenuto al termine del primo passo di Binutils) avviando il seguente comando dall'interno della directory binutils-build:
make -C ld install
D'ora in poi ogni cosa verrà linkata solo verso le librerie in /tools/lib.
Se per qualche ragione non si è dato retta al precedente avvertimento di tenere le directory dei sorgenti e di compilazione delle Binutils, ignorare il comando precedente. Il risultato è che c'è una piccola possibilità che i seguenti programmi di test si colleghino alle librerie del sistema in uso. Non è l'ideale, ma non è un grosso problema. La situazione verrà corretta all'installazione del secondo passo delle Binutils, un po' più avanti.
Ora che il linker corretto è installato, le directory dei sorgenti e di compilazione delle Binutils devono essere rimosse.
La prossima cosa da fare è correggere il nostro file di configurazione di GCC in modo che punti al nuovo linker dinamico. Un semplice script sed servirà allo scopo:
SPECFILE=`gcc --print-file specs` && sed 's@ /lib/ld-linux.so.2@ /tools/lib/ld-linux.so.2@g' \ $SPECFILE > tempspecfile && mv -f 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.
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.
C'è la possibilità che alcuni file include del sistema host abbiano trovato una strada nella directory include privata di GCC. Ciò può accadere come risultato del processo “fixincludes” di GCC, che funziona come parte della costruzione di GCC. Ciò viene spiegato con maggiori dettagli più avanti in questo capitolo. Eseguire il seguente comando per eliminare questa possibilità:
rm -vf /tools/lib/gcc/*/*/include/{pthread.h,bits/sigthread.h}
A questo punto è imperativo fermarsi ed assicurarsi che le funzioni di base (compilazione e collegamenti) 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-3.4.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
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è.