6.12. Riaggiustamento della Toolchain

Ora che le librerie C finali sono state installate, è tempo di aggiustare di nuovo la toolchain. La toolchain verrà messa a punto in modo che ogni nuovo programma compilato si collegherà a queste librerie. Questo è lo stesso processo usato nella fase “Messa a punto” all'inizio del Capitolo 5, ma con le sistemazioni invertite. Nel Capitolo 5 la chain è stata guidata dalle directory /{,usr/}lib dell'host alla nuova directory /tools/lib. Ora la chain verrà guidata dalla stessa directory /tools/lib alle directory di LFS /{,usr/}lib.

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 all'interno della 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 è necessario, 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 di GCC, così che punti al nuovo linker dinamico. Per farlo si usa un comando perl:

perl -pi -e 's@ /tools/lib/ld-linux.so.2@ /lib/ld-linux.so.2@g;' \
    -e 's@\*startfile_prefix_spec:\n@$_/usr/lib/@g;' \
    `gcc --print-file specs`

È 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 alla Sezione 5.2, “Note tecniche sulla Toolchain,”.

Attenzione

È 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 in precedenza.

Una volta sicuri che tutto sia a posto, cancellare i file di test:

rm -v dummy.c a.out