GCC-3.3.3 - Passo 2

Tempo approssimativo di costruzione:  11.0 SBU
Spazio necessario sul disco:     332.7 MB

Re-installazione di GCC

Gli strumenti necessari per testare GCC e Binutils sono ora installati: Tcl, Expect e DejaGnu. Pertanto ora possiamo ricostruire GCC e Binutils, linkarle verso le nuove Glibc e provare il tutto (se avviate le suite di test in questo capitolo). Una cosa da notare, tuttavia, è che queste suite di test sono fortemente dipendenti dal corretto funzionamento degli pseudo terminali (PTY) che sono messi a disposizione dall'host. Oggi, i PTY sono per lo più implementati attraverso il file system devpts. Potete verificare velocemente se il vostro sistema host è configurato correttamente riguardo a questo facendo un semplice test:

expect -c "spawn ls"

La risposta potrebbe essere:

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

Se ricevete il messaggio sopra, il vostro host non ha i suoi PTY settati correttamente. In questo caso non c'è modo di avviare le suite di test per GCC e Binutils fino a quando non siete in grado di risolvere la cosa. Potete consultare l'LFS Wiki su http://wiki.linuxfromscratch.org/ per altre informazioni su come avere PTY funzionanti.

Questa volta costruiremo sia il compilatore C che il C++, perciò dovrete scompattare sia il tarball principale che g++ (e anche la testsuite, se volete avviare i test). Scompattateli nella vostra directory di lavoro, si metteranno tutti nella sottodirectory gcc-3.3.3/.

Correggete prima un problema e fate un importante aggiustamento:

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

La prima patch disabilita lo script di GCC “fixincludes”. In precedenza abbiamo parlato brevemente di questo, ma una piccola spiegazione più approfondita del processo "fixincludes" qui è necessaria. In normali circostanze, lo script di GCC "fixincludes" analizza il vostro sistema alla ricerca di files header che devono essere corretti. Potrebbe trovare qualche file header di Glibc sul vostro sistema host che ha bisogno di correzione, correggerlo e metterlo nella directory "include" privata di GCC. In seguito, nel Capitolo 6, dopo che abbiamo installato le nuove Glibc, questa directory "include" privata verrà cercata prima della directory include di sistema e il risultato sarà che GCC troverà gli header corretti nel sistema host, che per lo più non corrisponderanno alla versione di Glibc attualmente usata per il sistema LFS.

La seconda patch cambia la locazione di default del linker dinamico di GCC (tipicamente ld-linux.so.2). Inoltre rimuove /usr/include dal percorso di ricerca di GCC. Applicare ora la patch piuttosto che sistemare il file di configurazione dopo l'installazione garantisce che il nostro nuovo linker dinamico verrà usato durante la costruzione attuale di GCC. Ciò significa che tutti i definitivi (e temporanei) binari creati durante la costruzione si linkeranno verso le nuove Glibc.

[Important]

Importante

Le patch precedenti sono critiche per garantire che la costruzione complessiva abbia successo. Non dimenticate di applicarle.

Create di nuovo una directory di costruzione separata:

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

Prima di iniziare a costruire GCC, ricordatevi di eliminare ogni variabile ambiente che si sovrapponga ai flag di ottimizzazione predefiniti.

Ora preparate GCC per la compilazione:

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

Il significato delle opzioni di configurazione è:

  • --enable-clocale=gnu: questa opzione assicura che il corretto modello locale sia selezionato in qualsiasi circostanza per le librerie C++. Se lo script di configurazione trova il de_DE locale installato, selezionerà il corretto modello locale gnu. Tuttavia, coloro che non installano il de_DE locale correranno il rischio di costruire librerie C++ incompatibili ABI, per via della scelta errata del modello locale generic.

  • --enable-threads=posix: questa opzione abilita la gestione delle eccezioni C++ per codice multi-thread.

  • --enable-__cxa_atexit: questa opzione permette l'uso di __cxa_atexit, invece che atexit, per registrare i distruttori C++ per oggetti locali statici e oggetti globali, ed è essenziale per una gestione dei distruttori aderente agli standard. Influisce anche sull'ABI di C++ e in più permette di avere librerie condivise C++ e programmi C++ che sono interoperabili con altre distribuzioni Linux.

  • --enable-languages=c,c++: questa opzione assicura che siano costruiti sia il compilatore C che il compilatore C++.

Compilate il pacchetto:

make

Non c'è alcun bisogno ora di usare il target bootstrap, poiché il compilatore che stiamo usando per compilare questo GCC è stato costruito esattamente dalla stessa versione dei sorgenti GCC che abbiamo usato prima.

La compilazione è ora completa. Come accennato prima, non raccomandiamo di avviare le suite di test per gli strumenti temporanei qui in questo capitolo. Se tuttavia volete avviare ugualmente la suite di test, potete farlo con il seguente comando:

make -k check

Il flag -k è usato per far sì che la suite di test arrivi al termine e non si fermi al primo fallimento. La suite di test di GCC è molto approfondita ed è quasi sicuro che generi qualche fallimento. Per avere un sommario dei risultati della suite di test, avviate questo:

../gcc-3.3.3/contrib/test_summary

(Per i soli sommari, fate un pipe dell'output attraverso grep -A7 Summ.)

Potete confrontare i vostri risultati con quelli postati sulla mailing list gcc-testresults per configurazioni simili alla vostra. Per un esempio su come possa apparire GCC-3.3.3 su un i686-pc-linux-gnu, vedete http://gcc.gnu.org/ml/gcc-testresults/2004-01/msg00826.html.

Notate che il risultato contiene:

* 1 XPASS (unexpected pass) for g++
* 1 FAIL (unexpected failure) for gcc
* 24 XPASS's for libstdc++

L'"unexpected pass" per g++ è dovuto all'uso di --enable-__cxa_atexit. Apparentemente non tutte le piattaforme supportate da GCC hanno il supporto per “__cxa_atexit” nelle loro librerie C, così non è detto che questo test passi sempre.

I 24 "unexpected passes" per libstdc++ sono dovuti all'uso di --enable-clocale=gnu. Questa opzione, che è la scelta corretta su sitemi basati su Glibc di versione 2.2.5 e superiore, abilita nella libreria C di GNU un supporto locale che è superiore al modello generico che verrebbe altrimenti selezionato (che può essere applicabile se per esempio stavate usando Newlibc, Sun-libc o qualunque altra libc). La suite di test libstdc++ apparentemente si aspetta il modello generic, quindi non è detto che questi test passino sempre.

Avere qualche fallimento inatteso spesso è inevitabile. Gli sviluppatori di GCC normalmente lo sanno, ma non sono ancora riusciti a risolverli. Un caso particolare è il test filebuf_members nella suite di test della libreria standard di C++. Questo test è stato visto fallire in certe situazioni, ma avere successo in altre. In breve anche se i vostri risultati dovessero essere molto diversi da quelli nell'URL precedente, continuate tranquillamente.

E infine installate il pacchetto:

make install
[Note]

Nota

A questo punto raccomandiamo fortemente di ripetere il controllo di integrità che abbiamo eseguito in precedenza in questo capitolo. Fate riferimento alla sezione chiamata “Regolazione della toolchain” e ripetete il piccolo test di compilazione. Se il risultato è sbagliato, allora probabilmente avete dimenticato di applicare le patch di GCC sopra menzionate.

Dettagli su questo pacchetto si trovano nella sezione chiamata “Contenuti di GCC”.