Installazione di GCC da Linux from Scratch di OnWorks

Salta al contenuto

5.10.1. Installazione di GCC

La nostra prima build di GCC ha installato un paio di header di sistema interni. Normalmente uno di questi, limiti.h, a sua volta includerà il sistema corrispondente limiti.h intestazione, in questo caso, /strumenti/include/limiti.hTuttavia, al momento della prima compilazione di gcc /strumenti/include/limiti.h non esisteva, quindi l'intestazione interna installata da GCC è un file parziale e autonomo e non include le funzionalità estese dell'intestazione di sistema. Questo era sufficiente per compilare la libc temporanea, ma questa build di GCC ora richiede l'intestazione interna completa. Creare una versione completa dell'intestazione interna utilizzando un comando identico a quello che il sistema di compilazione di GCC esegue in circostanze normali:

cat gcc/limitx.h gcc/glimits.h gcc/limity.h > \

`dirname $($LFS_TGT-gcc -print-libgcc-file-name)`/include-fixed/limits.h

cat gcc/limitx.h gcc/glimits.h gcc/limity.h > \

`dirname $($LFS_TGT-gcc -print-libgcc-file-name)`/include-fixed/limits.h

Immagine

in gcc/config/{linux,i386/linux{,64}}.h

$file{,.orig} 's@/lib$64$\?$32$\?/ld@/tools&@g' \

's@/usr@/tools@g' $file.orig > $file

$file{,.orig} 's@/lib$64$\?$32$\?/ld@/tools&@g' \

's@/usr@/tools@g' $file.orig > $file

Ancora una volta, modifica la posizione del linker dinamico predefinito di GCC per utilizzare quello installato in /utensili.

per file fare

cp -uv sed -e

-e

per file fare

cp -uv sed -e

-e

eco '

#undef STANDARD_STARTFILE_PREFIX_1

#undef STANDARD_STARTFILE_PREFIX_2

#define STANDARD_STARTFILE_PREFIX_1 "/tools/lib/"

#define STANDARD_STARTFILE_PREFIX_2 ""' >> $file touch $file.orig

fatto

eco '

#undef STANDARD_STARTFILE_PREFIX_1

#undef STANDARD_STARTFILE_PREFIX_2

#define STANDARD_STARTFILE_PREFIX_1 "/tools/lib/"

#define STANDARD_STARTFILE_PREFIX_2 ""' >> $file touch $file.orig

fatto

Se si compila su x86_64, modificare il nome della directory predefinita per le librerie a 64 bit in "lib":

caso $(uname -m) in x86_64)

sed -e '/m64=/s/lib64/lib/' \

-i.orig gcc/config/i386/t-linux64

;;

che C

caso $(uname -m) in x86_64)

sed -e '/m64=/s/lib64/lib/' \

-i.orig gcc/config/i386/t-linux64

;;

che C

Come nella prima build di GCC, sono necessari i pacchetti GMP, MPFR e MPC. Decomprimete i tarball e spostateli nelle directory richieste:

tar -xf ../mpfr-4.0.2.tar.xz mv -v mpfr-4.0.2 mpfr

tar -xf ../gmp-6.1.2.tar.xz mv -v gmp-6.1.2 gmp

tar -xf ../mpc-1.1.0.tar.gz mv -v mpc-1.1.0 mpc

tar -xf ../mpfr-4.0.2.tar.xz mv -v mpfr-4.0.2 mpfr

tar -xf ../gmp-6.1.2.tar.xz mv -v gmp-6.1.2 gmp

tar -xf ../mpc-1.1.0.tar.gz mv -v mpc-1.1.0 mpc

Crea di nuovo una directory di build separata:

mkdir -v build build cd

Prima di iniziare a compilare GCC, ricordatevi di deselezionare tutte le variabili d'ambiente che sovrascrivono i flag di ottimizzazione predefiniti. Ora preparate GCC per la compilazione:

CC=$LFS_TGT-gcc \

CXX=$LFS_TGT-g++ \

AR=$LFS_TGT-ar \

RANLIB=$LFS_TGT-ranlib \

../configura \

--prefix=/strumenti \

--con-prefisso-locale=/strumenti \

--with-native-system-header-dir=/tools/include \

--abilita-lingue=c,c++ \

--disable-libstdcxx-pch \

--disabilita-multilib \

--disabilita-bootstrap \

--disable-libgomp

CC=$LFS_TGT-gcc \

CXX=$LFS_TGT-g++ \

AR=$LFS_TGT-ar \

RANLIB=$LFS_TGT-ranlib \

../configura \

--prefix=/strumenti \

--con-prefisso-locale=/strumenti \

--with-native-system-header-dir=/tools/include \

--abilita-lingue=c,c++ \

--disable-libstdcxx-pch \

--disabilita-multilib \

--disabilita-bootstrap \

--disable-libgomp

Il significato delle nuove opzioni di configurazione:

--enable-linguaggi=c,c++

Questa opzione garantisce che vengano compilati sia il compilatore C che quello C++.

--disable-libstdcxx-pch

Non compilare l'intestazione precompilata (PCH) per libstdc++Occupa molto spazio e non ci serve a nulla.

--disabilita-bootstrap

Per le build native di GCC, l'impostazione predefinita è quella di eseguire una build "bootstrap". Questa non si limita a compilare GCC, ma lo compila più volte. Utilizza i programmi compilati in un primo ciclo per compilarsi una seconda volta e poi di nuovo una terza volta. La seconda e la terza iterazione vengono confrontate per assicurarsi che possa riprodursi in modo impeccabile. Ciò implica anche che la compilazione sia stata eseguita correttamente. Tuttavia, il metodo di build LFS dovrebbe fornire un compilatore affidabile senza la necessità di eseguire il bootstrap ogni volta.

Compila il pacchetto:

make

Installa il pacchetto:

make install

Come tocco finale, crea un collegamento simbolico. Molti programmi e script eseguono cc invece di gcc, che viene utilizzato per mantenere i programmi generici e quindi utilizzabili su tutti i tipi di sistemi UNIX in cui il compilatore GNU C non è sempre installato. Esecuzione cc lascia l'amministratore di sistema libero di decidere quale compilatore C installare:

ln -sv gcc /tools/bin/cc

Immagine

Attenzione

A questo punto, è fondamentale fermarsi e assicurarsi che le funzioni di base (compilazione e collegamento) della nuova toolchain funzionino come previsto. Per eseguire un controllo di integrità, eseguire i seguenti comandi:

echo 'int main(){}' > dummy.c cc dummy.c

readelf -l a.out | grep ': /strumenti'

echo 'int main(){}' > dummy.c cc dummy.c

readelf -l a.out | grep ': /strumenti'

Se tutto funziona correttamente, non dovrebbero esserci errori e l'output dell'ultimo comando sarà del tipo:

[Richiedente interprete del programma: /tools/lib64/ld-linux-x86-64.so.2]

Si noti che il linker dinamico sarà /tools/lib/ld-linux.so.2 per le macchine a 32 bit.

Se l'output non viene visualizzato come sopra o non viene visualizzato alcun output, significa che qualcosa non va. Indagare e ripercorrere i passaggi per individuare il problema e correggerlo. Questo problema deve essere risolto prima di continuare. Innanzitutto, eseguire nuovamente il controllo di integrità, utilizzando gcc invece di ccSe funziona, allora il /strumenti/bin/ cc manca il collegamento simbolico. Installare il collegamento simbolico come sopra. Quindi, assicurarsi che PERCORSO è corretto. Questo può essere verificato eseguendo echo $ PATH e verificando che /strumenti/bin è in cima alla lista. Se il PERCORSO è sbagliato potrebbe significare che non hai effettuato l'accesso come utente lfs o che qualcosa è andato storto nella Sezione 4.4, "Preparare l'ambiente".

Una volta che tutto è a posto, pulisci i file di prova:

rm -v dummy.c a.out