Ora che sono state installate le nuove e finali librerie C, è il momento di aggiustare di nuovo la toolchain. La aggiusteremo in modo che ogni nuovo programma compilato verrà collegato a queste nuove librerie. In effetti questa è la stessa cosa che abbiamo fatto nella fase di “Messa a punto” all'inizio del capitolo precedente, anche se sembra il contrario: allora abbiamo dirottato la chain dalla /{,usr/}lib dell'host alla nuova /tools/lib, ora la dirottiamo dalla stessa /tools/lib a /{,usr/}lib della LFS.
Iniziare aggiustando il linker. Per questo sono sate conservate le directory dei sorgenti e di costruzione dopo il secondo passo delle Binutils. Installare il linker aggiustato eseguendo il seguente comando dentro la directory binutils-build:
make -C ld INSTALL=/tools/bin/install install
Se per qualche ragione non si è dato retta al precedente avviso di conservare le directory sorgente e di costruzione di Binutils dal secondo passo nel Capitolo 5, o comunque sono state accidentalmente cancellate o semplicemente non è possibile accedervi, non ci si deve preoccupare, non tutto è perduto. Ignorare semplicemente il comando sopra. Il risultato sarà che il prossimo pacchetto, Binutils, verrà collegato verso le librerie C in /tools invece che in /{,usr/}lib. Non è l'ideale, tuttavia i nostri test hanno mostrato che i programmi binari risultanti delle Binutils dovrebbero essere identici.
D'ora in poi ogni programma compilato si collegherà solo alle librerie in /usr/lib e /lib. L'extra INSTALL=/tools/bin/install è necessaria perché il Makefile creato durante il secondo passo contiene ancora i riferimenti a /usr/bin/install, che ovviamente non sono ancora stati installati. Certe distribuzioni host contengono un link simbolico ginstall che nel Makefile ha la precedenza e quindi qui può creare problemi. Il comando precedente si occupa anche di questo.
Ora si possono rimuovere le directory dei sorgenti e di costruzione delle Binutils.
La prossima cosa da fare è correggere il file specs GCC così che punti al nuovo linker dinamico. Come poco fa, per farlo si usa un sed:
sed -i 's@ /tools/lib/ld-linux.so.2@ /lib/ld-linux.so.2@g' \ `gcc --print-file specs`
E' una buona idea controllare visivamente il file specs per verificare che i cambiamenti voluti siano stati apportati.
Se si sta lavorando su una piattaforma in cui il nome del linker dinamico è diverso da ld-linux.so.2, nel comando precedente si sostituisca “ld-linux.so.2” con il nome del linker dinamico della piattaforma. Se necessario fare riferimento a Sezione 5.3, “Note tecniche sulla Toolchain,”.
E' obbligatorio a questo punto fermarsi e assicurarsi che le funzioni di base (compilazione e collegamento) della toolchain aggiustata funzionino come ci si aspetta. Per questo eseguiremo una semplice verifica di integrità:
echo 'main(){}' > dummy.c cc dummy.c readelf -l a.out | grep ': /lib'
Se tutto funziona correttamente, non dovranno esserci errori, e l'output dell'ultimo comando dovrà essere il seguente (non considerando specifiche differenze per via del nome del linker dinamico):
[Requesting program interpreter: /lib/ld-linux.so.2]
Notare in particolare che /lib è ora il prefisso del nostro linker dinamico.
Se non si è avuto l'output come mostrato sopra, o non si è proprio avuto alcun output, allora c'è qualcosa di seriamente sbagliato. Bisogna investigare e ripercorrere i propri passi per trovare dove è il problema e correggerlo. Non c'è modo di continuare fino a quando non è stato fatto questo. Più probabilmente qualcosa è andato storto con il file specs corretto sopra.
Una volta sicuri che tutto sia a posto, cancellare i file di test:
rm dummy.c a.out