Risistemazione della toolchain
Ora che sono state installate le nuove e definitive 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 “Regolazione” all'inizio del capitolo precedente, anche se sembra il contrario: allora abbiamo guidato la chain dalla /{,usr/}lib dell'host alla nuova /tools/lib, ora la guidiamo dalla stessa /tools/lib a /{,usr/}lib della LFS.
Prima configuriamo il linker. Per questo abbiamo conservato le directory dei sorgenti e di costruzione dopo il secondo passo delle Binutils. Installate il linker aggiustato eseguendo il seguente comando dentro la directory binutils-build:
make -C ld INSTALL=/tools/bin/install install
![[Note]](../images/note.png)
Nota
Se per qualche ragione non avete dato retta al precedente avviso di conservare le directory sorgente e di costruzione di Binutils dal secondo passo nel Capitolo 5, o comunque le avete accidentalmente cancellate o semplicemente non avete accesso ad esse, non preoccupatevi, non tutto è perduto. Ignorate 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 verso le 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 noi ovviamente non abbiamo ancora installato. Certe distribuzioni host contengono un link simbolico ginstall che nel Makefile ha la precedenza e quindi qui può creare problemi. Il comando sopra si occupa anche di questo.
Ora potete rimuovere le directory dei sorgenti e di costruzione delle Binutils.
La prossima cosa da fare è correggere il nostro file specs GCC così che punti al nuovo linker dinamico. Come poco fa, per farlo usiamo un sed:
SPECFILE=/tools/lib/gcc-lib/*/*/specs &&
sed -e 's@ /tools/lib/ld-linux.so.2@ /lib/ld-linux.so.2@g' \
$SPECFILE > newspecfile &&
mv -f newspecfile $SPECFILE &&
unset SPECFILE
Ancora, raccomandiamo di tagliare e incollare i comandi sopra. E proprio come prima, è una buona idea controllare a vista il file specs per verificare che i cambiamenti voluti siano stati fatti.
![[Important]](../images/important.png)
Importante
Se state lavorando su una piattaforma in cui il nome del linker dinamico è diverso da ld-linux.so.2, dovete sostituire ld-linux.so.2 con il nome del linker dinamico della vostra piattaforma nel comando sopra. Fate riferimento alla sezione chiamata “Note tecniche sulla toolchain” se necessario.
![[Caution]](../images/caution.png)
Attenzione
È obbligatorio a questo punto fermarsi e assicurarsi che le funzioni di base (compilazione e collegamento) della toolchain sistemata funzionino come ci aspettiamo. 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 devono esserci errori, e l'output dell'ultimo comando sarà (non considerando specifiche differenze per via del nome del linker dinamico):
[Requesting program interpreter: /lib/ld-linux.so.2]
Notate in particolare che /lib è ora il prefisso del nostro linker dinamico.
Se non avete avuto l'output come mostrato sopra, o non avete proprio avuto alcun output, allora c'è qualcosa di seriamente sbagliato. Dovrete investigare e ripercorrere i vostri passi per trovare dove è il problema e correggerlo. Non c'è modo di continuare fino a quando non avete fatto questo. Più probabilmente qualcosa è andato storto con il file specs corretto sopra.
Una volta che siete sicuri che tutto sia a posto, cancellate i file di test:
rm dummy.c a.out