6.12. Riaggiustamento della Toolchain

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

Nota

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.

Importante

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,”.

Attenzione

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