Installazione di GCC da Linux from Scratch di OnWorks

Salta al contenuto

6.21.1. Installazione di GCC

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

La documentazione di GCC consiglia di compilare GCC in una directory di build dedicata:

mkdir -v build build cd

Preparare GCC per la compilazione:

SED=sed \

../configure --prefix=/usr \

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

--disabilita-multilib \

--disabilita-bootstrap \

--with-system-zlib

SED=sed \

../configure --prefix=/usr \

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

--disabilita-multilib \

--disabilita-bootstrap \

--with-system-zlib

Si noti che per altri linguaggi alcuni prerequisiti non sono ancora disponibili. Consultare il BLFS Book per istruzioni su come compilare tutti i linguaggi supportati da GCC.

Significato dei nuovi parametri di configurazione:

SED=sed

L'impostazione di questa variabile di ambiente impedisce un percorso hardcoded per /tools/bin/sed.

--with-system-zlib

Questa opzione indica a GCC di collegarsi alla copia installata nel sistema della libreria Zlib, anziché alla propria copia interna.

Immagine

Compila il pacchetto:

make

Consigli

In questa sezione, la suite di test per GCC è considerata critica. Non saltarla in nessuna circostanza.

Consigli

In questa sezione, la suite di test per GCC è considerata critica. Non saltarla in nessuna circostanza.

È noto che un set di test nella suite di test GCC esaurisce lo stack, quindi aumentare le dimensioni dello stack prima di eseguire i test:

limite massimo -s 32768

Prova i risultati come utente senza privilegi, ma non fermarti agli errori:

chown -Rv nessuno .

su nessuno -s /bin/bash -c "PATH=$PATH make -k check"

chown -Rv nessuno .

su nessuno -s /bin/bash -c "PATH=$PATH make -k check"

Per ricevere un riepilogo dei risultati della suite di test, eseguire:

../contrib/test_summary

Solo per i riepiloghi, inoltra l'output tramite grep -A7 Sommario.

I risultati possono essere confrontati con quelli disponibili su http://www.linuxfromscratch.org/lfs/build-logs/9.0/ e https://gcc.gnu.org/ml/gcc-testresults/.

È noto che sei test relativi a get_time falliscono. Apparentemente sono correlati alle impostazioni locali en_HK.

È noto che due test denominati lookup.cc e reverse.cc in experimental/net falliscono nell'ambiente chroot LFS perché richiedono /etc/hosts e iana-etc.

È noto che due test denominati pr57193.c e pr90178.c non riescono.

Non è sempre possibile evitare alcuni errori imprevisti. Gli sviluppatori GCC sono solitamente a conoscenza di questi problemi, ma non li hanno ancora risolti. A meno che i risultati dei test non siano molto diversi da quelli riportati all'URL sopra indicato, è possibile continuare senza problemi.

Installa il pacchetto e rimuovi una directory non necessaria:

make install

rm -rf /usr/lib/gcc/$(gcc -dumpmachine)/9.2.0/include-fixed/bits/

make install

rm -rf /usr/lib/gcc/$(gcc -dumpmachine)/9.2.0/include-fixed/bits/

La directory di compilazione GCC è di proprietà di nessuno ora e la proprietà della directory di intestazione installata (e del suo contenuto) sarà errata. Cambia la proprietà in radice utente e gruppo:

chown -v -R radice:radice \

/usr/lib/gcc/*linux-gnu/9.2.0/include{,-fixed}

chown -v -R radice:radice \

/usr/lib/gcc/*linux-gnu/9.2.0/include{,-fixed}

Creare un collegamento simbolico richiesto dall'FHS per ragioni "storiche".

ln -sv ../usr/bin/cpp /lib

Molti pacchetti usano il nome cc per chiamare il compilatore C. Per soddisfare questi pacchetti, crea un collegamento simbolico:

ln -sv gcc /usr/bin/cc

Aggiungere un collegamento simbolico di compatibilità per abilitare la creazione di programmi con Link Time Optimization (LTO):

installa -v -dm755 /usr/lib/bfd-plugins

ln -sfv ../../libexec/gcc/$(gcc -dumpmachine)/9.2.0/liblto_plugin.so \

/usr/lib/bfd-plugins/

installa -v -dm755 /usr/lib/bfd-plugins

ln -sfv ../../libexec/gcc/$(gcc -dumpmachine)/9.2.0/liblto_plugin.so \

/usr/lib/bfd-plugins/

Ora che la nostra toolchain finale è pronta, è importante assicurarsi nuovamente che la compilazione e il collegamento funzionino come previsto. Per farlo, eseguiamo gli stessi controlli di integrità già eseguiti in precedenza nel capitolo:

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

cc dummy.c -v -Wl,--verbose &> dummy.log readelf -l a.out | grep ': /lib'

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

cc dummy.c -v -Wl,--verbose &> dummy.log readelf -l a.out | grep ': /lib'

Non dovrebbero esserci errori e l'output dell'ultimo comando sarà (tenendo conto delle differenze specifiche della piattaforma nel nome del linker dinamico):

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

Ora assicuriamoci di essere configurati per utilizzare i file di avvio corretti:

grep -o '/usr/lib.*/crt[1in].*succeeded' dummy.log

L'output dell'ultimo comando dovrebbe essere:

/usr/lib/gcc/x86_64-pc-linux-gnu/9.2.0/../../../../lib/crt1.o riuscito

/usr/lib/gcc/x86_64-pc-linux-gnu/9.2.0/../../../../lib/crti.o riuscito

/usr/lib/gcc/x86_64-pc-linux-gnu/9.2.0/../../../../lib/crtn.o riuscito

/usr/lib/gcc/x86_64-pc-linux-gnu/9.2.0/../../../../lib/crt1.o riuscito

/usr/lib/gcc/x86_64-pc-linux-gnu/9.2.0/../../../../lib/crti.o riuscito

/usr/lib/gcc/x86_64-pc-linux-gnu/9.2.0/../../../../lib/crtn.o riuscito

A seconda dell'architettura della macchina, quanto sopra potrebbe differire leggermente, la differenza di solito è il nome della directory dopo /usr/lib/gccLa cosa importante da cercare qui è che gcc ha trovato tutti e tre crt*.o file sotto il / Usr / lib directory.

Verificare che il compilatore stia cercando i file di intestazione corretti:

grep -B4 '^ /usr/include' dummy.log

Questo comando dovrebbe restituire il seguente output:

#include <...> la ricerca inizia qui:

/usr/lib/gcc/x86_64-pc-linux-gnu/9.2.0/include

/usr/local/include

/usr/lib/gcc/x86_64-pc-linux-gnu/9.2.0/include-fixed

/ usr / include

#include <...> la ricerca inizia qui:

/usr/lib/gcc/x86_64-pc-linux-gnu/9.2.0/include

/usr/local/include

/usr/lib/gcc/x86_64-pc-linux-gnu/9.2.0/include-fixed

/ usr / include

Di nuovo, tieni presente che la directory denominata in base alla tripletta di destinazione potrebbe essere diversa da quella sopra indicata, a seconda dell'architettura.

Successivamente, verificare che il nuovo linker venga utilizzato con i percorsi di ricerca corretti:

grep 'SEARCH.*/usr/lib' dummy.log |sed 's|; |\n|g'

I riferimenti ai percorsi che hanno componenti con '-linux-gnu' dovrebbero essere ignorati, altrimenti l'output dell'ultimo comando dovrebbe essere:

SEARCH_DIR("/usr/x86_64-pc-linux-gnu/lib64") SEARCH_DIR("/usr/local/lib64") SEARCH_DIR("/lib64")

SEARCH_DIR("/usr/lib64") SEARCH_DIR("/usr/x86_64-pc-linux-gnu/lib") SEARCH_DIR("/usr/local/lib") SEARCH_DIR("/lib")

SEARCH_DIR("/usr/lib");

SEARCH_DIR("/usr/x86_64-pc-linux-gnu/lib64") SEARCH_DIR("/usr/local/lib64") SEARCH_DIR("/lib64")

SEARCH_DIR("/usr/lib64") SEARCH_DIR("/usr/x86_64-pc-linux-gnu/lib") SEARCH_DIR("/usr/local/lib") SEARCH_DIR("/lib")

SEARCH_DIR("/usr/lib");

Un sistema a 32 bit potrebbe visualizzare più directory diverse. Ad esempio, ecco l'output di una macchina i686:

SEARCH_DIR("/usr/i686-pc-linux-gnu/lib32") SEARCH_DIR("/usr/local/lib32") SEARCH_DIR("/lib32")

SEARCH_DIR("/usr/lib32") SEARCH_DIR("/usr/i686-pc-linux-gnu/lib") SEARCH_DIR("/usr/local/lib") SEARCH_DIR("/lib")

SEARCH_DIR("/usr/lib");

SEARCH_DIR("/usr/i686-pc-linux-gnu/lib32") SEARCH_DIR("/usr/local/lib32") SEARCH_DIR("/lib32")

SEARCH_DIR("/usr/lib32") SEARCH_DIR("/usr/i686-pc-linux-gnu/lib") SEARCH_DIR("/usr/local/lib") SEARCH_DIR("/lib")

SEARCH_DIR("/usr/lib");

Ora assicuriamoci di utilizzare la libc corretta:

grep "/lib.*/libc.so.6 " dummy.log

L'output dell'ultimo comando dovrebbe essere:

tentativo di apertura di /lib/libc.so.6 riuscito

Infine, assicurati che GCC utilizzi il linker dinamico corretto:

grep ha trovato dummy.log

L'output dell'ultimo comando dovrebbe essere (tenendo conto delle differenze specifiche della piattaforma nel nome del linker dinamico):

trovato ld-linux-x86-64.so.2 in /lib/ld-linux-x86-64.so.2

Se l'output non appare come mostrato sopra o non viene ricevuto affatto, allora c'è qualcosa di gravemente sbagliato. Indagare e ripercorrere i passaggi per scoprire dove si trova il problema e correggerlo. Il motivo più probabile è che qualcosa sia andato storto con la modifica del file delle specifiche. Eventuali problemi dovranno essere risolti prima di continuare con il processo.

Una volta che tutto funziona correttamente, ripulisci i file di prova:

rm -v dummy.c a.out dummy.log

Infine, sposta un file fuori posto:

mkdir -pv /usr/share/gdb/auto-load/usr/lib

mv -v /usr/lib/*gdb.py /usr/share/gdb/auto-load/usr/lib

mkdir -pv /usr/share/gdb/auto-load/usr/lib

mv -v /usr/lib/*gdb.py /usr/share/gdb/auto-load/usr/lib