Linux From Scratch - Versione 6.2

Capitolo 5. Costruzione di un sistema temporaneo

5.11. GCC-4.0.3 - Passo 2

Il pacchetto GCC contiene la collezione di compilatori GNU, che include i compilatori C e C++.

Tempo di costruzione approssimativo: 4.2 SBU
Spazio necessario su disco: 443 MB

5.11.1. Reinstallazione di GCC

I tool richiesti per testare GCC e Binutils (Tcl, Expect e DejaGNU) sono ora installati. GCC e Binutils possono ora essere ricostruiti, linkandoli verso la nuova Glibc e testandoli appropriatamente (se si esegue la suite di test in questo capitolo). Prendere nota che queste suite di test sono altamente dipendenti da PTY funzionanti correttamente, che sono forniti dal sistema in uso. I PTY solitamente sono implementati attraverso il file system devpts. Verificare che il sistema in uso sia impostato correttamente a questo riguardo eseguendo un test veloce: 

expect -c "spawn ls"

La risposta può essere: 

The system has no more ptys.
Ask your system administrator to create more.

Se viene ricevuto il precedente messaggio il sistema in uso non ha i suoi PTY impostati correttamente. In questo caso non c'è modo di eseguire le suite di test per GCC e Binutils fino a quando questo problema non viene risolto. Consultare la FAQ di LFS su http://www.linuxfromscratch.org//lfs/faq.html#no-ptys per ulteriori informazioni su come far funzionare i PTY.

Come spiegato precedentemente in Sezione 5.7, «Regolazione della toolchain», in normali circostanze lo script GCC fixincludes viene eseguito per correggere potenziali corruzioni di file header. Siccome a questo punto sono giá stati installati GCC-4.0.3 e Glibc-2.3.6 e i loro rispettivi file header si sà che non richiedono correzioni, lo script fixincludes non è richiesto. Come detto precedentemente, lo script può in effetti inquinare l'ambiente di compilazione installando header corretti dal sistema host nella directory include privata di GCC. L'esecuzione dello script fixincludes può essere eliminata immettendo i seguenti comandi: 

cp -v gcc/Makefile.in{,.orig} &&
sed 's@\./fixinc\.sh@-c true@' gcc/Makefile.in.orig > gcc/Makefile.in

La compilazione con target bootstrap eseguita in Sezione 5.4, «GCC-4.0.3 - Passo 1» ha costruito GCC con il flag di compilazione -fomit-frame-pointer. La compilazione senza target bootstrap omette questo flag di default, così eseguire il seguente sed per usarlo al fine di assicurare una costruzione uniforme del compilatore. 

cp -v gcc/Makefile.in{,.tmp} &&
sed 's/^XCFLAGS =$/& -fomit-frame-pointer/' gcc/Makefile.in.tmp \
  > gcc/Makefile.in

Applicare la seguente patch per modificare la locazione del linker dinamico di default del GCC (tipicamente ld-linux.so.2): 

patch -Np1 -i ../gcc-4.0.3-specs-1.patch

La patch suddetta rimuove anche /usr/include dal path di ricerca degli include dui GCC. Applicare la patch adesso piuttosto che sistemare il file specs dopo l'installazione assicura che sia utilizzato il nuovo linker dinamico durante l'effettiva compilazione di GCC. Ossia, tutti i binari creati durante la compilazione punteranno alla nuova Glibc.

[Importante]

Importante

Le precedenti patch sono critiche per assicurare il successo della costruzione complessiva. Non dimenticare di applicarle.

Creare di nuovo una directory separata di costruzione: 

mkdir -v ../gcc-build
cd ../gcc-build

Prima di avviare la costruzione di GCC, ricordare di disallocare ogni variabile ambiente che sovrascriva i flag di ottimizzazione di default.

Preparare GCC per la compilazione: 

../gcc-4.0.3/configure --prefix=/tools \
--with-local-prefix=/tools --enable-clocale=gnu \
--enable-shared --enable-threads=posix \
--enable-__cxa_atexit --enable-languages=c,c++ \
--disable-libstdcxx-pch

Significato delle nuove opzioni di configurazione:

--enable-clocale=gnu

Questa opzione assicura che venga selezionato il corretto modello locale per le librerie C++ in tutte le circostanze. Se lo script configure trova la localizzazione de_DE installata, selezionerà il modello gnu corretto di localizzazione. Tuttavia se la localizzazione de_DE non è installata, c'è il rischio di costruire delle librerie C++ incompatibili con le Application Binary Interface (ABI), poiché potrebbe venire selezionato il modello scorretto di localizzazione generica.

--enable-threads=posix

Questa abilita la gestione dell'eccezione C++ per il codice multi-threaded.

--enable-__cxa_atexit

Questa opzione permette l'uso di __cxa_atexit, piuttosto che atexit per registrare i distruttori C++ per oggetti statici e globali. Questa opzione essenzialmente è per una gestione dei distruttori pienamente conforme agli standard. Incide anche sull'ABI C++, pertanto il risultato saranno librerie condivise C++ e programmi C++ interoperabili con altre distribuzioni Linux.

--enable-languages=c,c++

Questa opzione assicura che entrambi i compilatori C e C++ siano costruiti.

--disable-libstdcxx-pch

Non costruisce l'header precompilato (PCH) per libstdc++. Prende un sacco di spazio, e non ce ne facciamo nulla.

Compilare il pacchetto: 

make

Non c'è bisogno di usare il target bootstrap ora, poiché il compilatore usato per compilare GCC è stato costruito esattamente a partire dalla stessa versione dei sorgenti GCC usati in precedenza.

La compilazione è ora completa. Come citato precedentemente eseguire le suite di test per i tool temporanei compilati in questo capitolo non è obbligatorio. Per eseguire comunque la suite di test di GCC usare il seguente comando: 

make -k check

Il flag -k è usato per far sì che la suite di test funzioni fino al completamento e non si fermi al primo fallimento. La suite di test di GCC è molto completa ed è praticamente sicuro che generi qualche fallimento.

Per una discussione sui fallimenti dei test di particolare importanza, prego vedere Sezione 6.12, «GCC-4.0.3.»

Installare il pacchetto: 

make install
[Attenzione]

Attenzione

A questo punto è imperativo fermarsi ed assicurarsi che le funzioni di base (compilazione e link) 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-4.0.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

Dettagli su questo pacchetto si trovano nella Sezione 6.12.2, «Contenuti di GCC.»