Instalarea GCC de la Linux de la zero de către OnWorks

Salt la conținut

<Înapoi | Cuprins | Următor>

6.21.1. Instalarea GCC

Dacă construiți pe x86_64, schimbați numele de director implicit pentru bibliotecile pe 64 de biți în „lib”:

caz $(uname -m) în x86_64)

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

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

;;

ESAC

caz $(uname -m) în x86_64)

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

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

;;

ESAC

Documentația GCC recomandă construirea GCC într-un director de compilare dedicat:

mkdir -v build cd build

Pregătiți GCC pentru compilare:

SED=sed \

../configure --prefix=/usr \

--enable-languages=c,c++ \

--disable-multilib \

--disable-bootstrap \

--with-system-zlib

SED=sed \

../configure --prefix=/usr \

--enable-languages=c,c++ \

--disable-multilib \

--disable-bootstrap \

--with-system-zlib

Rețineți că pentru alte limbi, există anumite cerințe preliminare care nu sunt încă disponibile. Consultați Cartea BLFS pentru instrucțiuni despre cum să construiți toate limbile acceptate de GCC.

Semnificația noilor parametri de configurare:

SED=sed

Setarea acestei variabile de mediu previne o cale hard-coded către /tools/bin/sed.

--with-system-zlib

Acest comutator îi spune GCC să se conecteze la copia instalată de sistem a bibliotecii Zlib, mai degrabă decât la propria copie internă.

imagine

Compilați pachetul:

face

Important

În această secțiune, suita de teste pentru GCC este considerată critică. Nu sări peste el sub nicio circumstanță.

Important

În această secțiune, suita de teste pentru GCC este considerată critică. Nu sări peste el sub nicio circumstanță.

Se știe că un set de teste din suita de teste GCC epuizează stiva, așa că măriți dimensiunea stivei înainte de a rula testele:

ulimit -s 32768

Testați rezultatele ca utilizator neprivilegiat, dar nu vă opriți la erori:

chown -Rv nimeni .

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

chown -Rv nimeni .

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

Pentru a primi un rezumat al rezultatelor suitei de teste, rulați:

../contrib/test_summary

Numai pentru rezumate, transmiteți rezultatul grep -A7 Sum.

Rezultatele pot fi comparate cu cele aflate la http://www.linuxfromscratch.org/lfs/build-logs/9.0/ și https://gcc.gnu. org/ml/gcc-testresults/.

Se știe că șase teste legate de get_time eșuează. Acestea sunt aparent legate de localitatea en_HK.

Două teste numite lookup.cc și reverse.cc în experimental/net sunt cunoscute că eșuează în mediul LFS chroot, deoarece necesită /etc/hosts și iana-etc.

Se știe că două teste denumite pr57193.c și pr90178.c eșuează.

Câteva eșecuri neașteptate nu pot fi evitate întotdeauna. Dezvoltatorii GCC sunt de obicei conștienți de aceste probleme, dar nu le-au rezolvat încă. Cu excepția cazului în care rezultatele testului sunt foarte diferite de cele de la adresa URL de mai sus, este sigur să continuați.

Instalați pachetul și eliminați un director care nu este necesar:

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/

Directorul de compilare GCC este deținut de nimeni acum și proprietatea directorului antet instalat (și conținutul acestuia) va fi incorectă. Schimbați proprietatea în rădăcină utilizator și grup:

chown -v -R root:root \

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

chown -v -R root:root \

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

Creați un link simbolic cerut de FHS din motive „istorice”.

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

Multe pachete folosesc numele cc pentru a apela compilatorul C. Pentru a satisface aceste pachete, creați un link simbolic:

ln -sv gcc /usr/bin/cc

Adăugați un link simbolic de compatibilitate pentru a activa programe de creare cu Link Time Optimization (LTO):

instalați -v -dm755 /usr/lib/bfd-plugins

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

/usr/lib/bfd-plugins/

instalați -v -dm755 /usr/lib/bfd-plugins

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

/usr/lib/bfd-plugins/

Acum că lanțul nostru de instrumente final este în vigoare, este important să ne asigurăm din nou că compilarea și conectarea vor funcționa conform așteptărilor. Facem acest lucru efectuând aceleași verificări ca și mai devreme în capitol:

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'

Nu ar trebui să existe erori, iar rezultatul ultimei comenzi va fi (permițând diferențe specifice platformei în numele linkerului dinamic):

[Se solicită interpretul de program: /lib64/ld-linux-x86-64.so.2]

Acum asigurați-vă că suntem configurați pentru a folosi fișierele de pornire corecte:

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

Ieșirea ultimei comenzi ar trebui să fie:

/usr/lib/gcc/x86_64-pc-linux-gnu/9.2.0/../../../../lib/crt1.o a reușit

/usr/lib/gcc/x86_64-pc-linux-gnu/9.2.0/../../../../lib/crti.o a reușit

/usr/lib/gcc/x86_64-pc-linux-gnu/9.2.0/../../../../lib/crtn.o a reușit

/usr/lib/gcc/x86_64-pc-linux-gnu/9.2.0/../../../../lib/crt1.o a reușit

/usr/lib/gcc/x86_64-pc-linux-gnu/9.2.0/../../../../lib/crti.o a reușit

/usr/lib/gcc/x86_64-pc-linux-gnu/9.2.0/../../../../lib/crtn.o a reușit

În funcție de arhitectura mașinii dvs., cele de mai sus pot diferi ușor, diferența fiind de obicei numele directorului după /usr/lib/gcc. Lucrul important de căutat aici este că gcc le-a găsit pe toate trei crt*.o fișiere sub / Usr / lib director.

Verificați dacă compilatorul caută fișierele de antet corecte:

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

Această comandă ar trebui să returneze următoarea ieșire:

#include <...> căutarea începe aici:

/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 <...> căutarea începe aici:

/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

Din nou, rețineți că directorul numit după tripletul țintă poate fi diferit de cel de mai sus, în funcție de arhitectura dvs.

Apoi, verificați dacă noul linker este utilizat cu căile de căutare corecte:

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

Referințele la căile care au componente cu „-linux-gnu” ar trebui ignorate, dar în caz contrar rezultatul ultimei comenzi ar trebui să fie:

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 sistem pe 32 de biți poate vedea câteva directoare diferite. De exemplu, iată rezultatul de la o mașină 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");

Apoi, asigurați-vă că folosim libc-ul corect:

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

Ieșirea ultimei comenzi ar trebui să fie:

încercarea de a deschide /lib/libc.so.6 a reușit

În cele din urmă, asigurați-vă că GCC utilizează linkerul dinamic corect:

grep găsit dummy.log

Ieșirea ultimei comenzi ar trebui să fie (permițând diferențe specifice platformei în numele linkerului dinamic):

găsit ld-linux-x86-64.so.2 la /lib/ld-linux-x86-64.so.2

Dacă ieșirea nu apare așa cum se arată mai sus sau nu este primită deloc, atunci ceva este în neregulă. Investigați și reveniți pe pașii pentru a afla unde este problema și remediați-o. Motivul cel mai probabil este că ceva nu a mers prost cu ajustarea fișierului cu specificații. Orice problemă va trebui rezolvată înainte de a continua procesul.

După ce totul funcționează corect, curățați fișierele de testare:

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

În cele din urmă, mutați un fișier deplasat:

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

<Înapoi | Cuprins | Următor>