5.11. GCC-3.4.3 - Passo 2

Tempo approssimativo di costruzione: 11.0 SBU
spazio su disco richiesto: 292 MB
L'installazione dipende da: Bash, Binutils, Coreutils, Diffutils, Findutils, Gawk, Gettext, Glibc, Grep, Make, Perl, Sed, Texinfo

5.11.1. Reinstallazione di GCC

Questo pacchetto è noto per avere problemi quando i suoi flag di ottimizzazione (incluse le opzioni -march e -mcpu) vengono cambiati. Se è stata definita una qualunque delle variabili ambiente che si sovrappone alle ottimizzazioni di default, come CFLAGS e CXXFLAGS, disallocarle quando si costruisce 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.

Dapprima correggere un problema noto e fare una sistemazione essenziale:

patch -Np1 -i ../gcc-3.4.3-no_fixincludes-1.patch
patch -Np1 -i ../gcc-3.4.3-specs-1.patch

La prima patch disabilita lo script GCC di fixincludes. Questo è stato brevemente menzionato in precedenza, ma qui è autorizzata una spiegazione più approfondita del processo fixincludes. In circostanze normali lo script GCC di fixincludes scansiona il sistema alla ricerca di file header, che devono essere corretti. Potrebbe trovare che alcuni dei file header di Glibc sul sistema in uso devono venire corretti, li correggerebbe e li metterebbe nella sottodirectory include privata di GCC. Nel Capitolo 6, dopo che sono state installate le Glibc più nuove, questa directory include privata verrà cercata prima della directory include di sistema. Il risultato potrebbe essere che GCC corregga header del sistema host, che molto facilmente non corrisponderanno alla versione di Glibc usata per il sistema LFS.

La seconda patch cambia la locazione di default del linker dinamico di GCC (tipicamente ld-linux.so.2). Rimuove anche /usr/include dal percorso di ricerca dell'include di GCC. Patchando ora piuttosto che aggiustare più tardi l'installazione del file specs, assicura che il nuovo linker dinamico sia usato durante la costruzione attuale di GCC. Ciò significa che tutti gli ultimi (e temporanei) binari creati durante la costruzione verranno linkati verso la 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 ../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-3.4.3/configure --prefix=/tools \
    --libexecdir=/tools/lib --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 ricevere un sommario dei risultati della suite di test, eseguire:

../gcc-3.4.3/contrib/test_summary

Per i soli sommari fare un pipe dell'output attraverso grep -A7 Summ.

I risultati possono essere confrontati con quelli che si trovano presso http://www.linuxfromscratch.org/lfs/build-logs/6.1/.

Alcuni fallimenti inattesi sono inevitabili. Gli sviluppatori di GCC di solito sono a conoscenza di questi problemi, ma non li hanno ancora risolti. A meno che i risultati dei test non siano ampiamente diversi da quelli del precedente URL, si può tranquillamente continuare.

Installare il pacchetto:

make install
[Nota]

Nota

A questo punto si raccomanda fortemente di ripetere il test di integrità che è stato eseguito precedentemente in questo capitolo. Fare riferimento a Sezione 5.7, “Regolazione della toolchain,” e ripetere il test di compilazione. Se il risultato è sbagliato, la ragione più probabile è che la patch GCC Specs non sia stata correttamente applicata.

Dettagli su questo pacchetto si trovano nella Sezione 6.14.2, “Contenuti di GCC.”