8.26. GCC-12.2.0

8.26.1. Installasjon av GCC

Hvis du bygger på x86_64, endre standard mappenavn for 64-bit bibliotekene til “lib”:

case $(uname -m) in
  x86_64)
    sed -e '/m64=/s/lib64/lib/' \
        -i.orig gcc/config/i386/t-linux64
  ;;
esac

GCC dokumentasjonen anbefaler å bygge GCC i en dedikert byggemappe:

mkdir -v build
cd       build

Forbered GCC for kompilering:

../configure --prefix=/usr            \
             LD=ld                    \
             --enable-languages=c,c++ \
             --enable-default-pie     \
             --enable-default-ssp     \
             --disable-multilib       \
             --disable-bootstrap      \
             --with-system-zlib

GCC støtter syv forskjellige dataspråk, men forutsetningene for de fleste av dem er ikke installert ennå. Se BLFS Bokens GCC side for instruksjoner om hvordan du bygger alle GCCs støttede språk.

Kompiler pakken:

make

Et sett med tester i GCC testpakken er kjent for å bruke opp standard stabel (stack), så øk stabelstørrelsen før du kjører testene:

ulimit -s 32768

Test resultatene som en ikke-privilegert bruker, men ikke stopp ved feil:

chown -Rv tester .
su tester -c "PATH=$PATH make -k check"

For å trekke ut et sammendrag av resultatene for testpakken, kjør:

../contrib/test_summary

For å filtrere ut bare sammendragene, kanaliser utdataene gjennom grep -A7 Summ.

Resultatene kan sammenlignes med de som ligger på https://www.linuxfromscratch.org/lfs/build-logs/11.3/ og https://gcc.gnu.org/ml/gcc-testresults/.

I gcc er elleve tester i i386-testpakken kjent for å FEILE. Det er fordi testfilene ikke tar hensyn til --enable-default-pie alternativet.

Fire tester relatert til PR100400 kan rapporteres som både XPASS og FAIL når du tester g++-kompilatoren; testfilen er ikke godt skrevet.

Noen få uventede feil kan ikke alltid unngås. GCC utviklerne er vanligvis klar over disse problemene, men har ikke løst dem ennå. Med mindre testresultatene er svært forskjellige fra de på URLen ovenfor, er det trygt å fortsette.

Installer pakken:

make install

GCC byggemappen eies av tester nå og eierskapet til den installerte deklarasjonsmappen (og dens innhold) vil være feil. Endre eierskapet til root bruker og gruppe:

chown -v -R root:root \
    /usr/lib/gcc/$(gcc -dumpmachine)/12.2.0/include{,-fixed}

Lag en symbolkobling som kreves av FHS av "historiske" grunner.

ln -svr /usr/bin/cpp /usr/lib

Legg til en kompatibilitetssymbolkobling for å aktivere byggeprogrammer med optimalisering av koblingstid (LTO (Link Time Optimization)):

ln -sfv ../../libexec/gcc/$(gcc -dumpmachine)/12.2.0/liblto_plugin.so \
        /usr/lib/bfd-plugins/

Nå som vår endelige verktøykjede er på plass, er det viktig å sikre at kompilering og kobling vil fungere som forventet. Dette gjør vi ved å utføre noen sunnhetssjekker:

echo 'int main(){}' > dummy.c
cc dummy.c -v -Wl,--verbose &> dummy.log
readelf -l a.out | grep ': /lib'

Det bør ikke være noen feil, og utdataen av den siste kommandoen vil være (som gir rom for plattformspesifikke forskjeller i det dynamiske linkernavnet):

[Requesting program interpreter: /lib64/ld-linux-x86-64.so.2]

Sørg nå for at vi er konfigurert til å bruke de riktige startfilene:

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

Utdata fra den siste kommandoen bør være:

/usr/lib/gcc/x86_64-pc-linux-gnu/12.2.0/../../../../lib/Scrt1.o succeeded
/usr/lib/gcc/x86_64-pc-linux-gnu/12.2.0/../../../../lib/crti.o succeeded
/usr/lib/gcc/x86_64-pc-linux-gnu/12.2.0/../../../../lib/crtn.o succeeded

Avhengig av maskinarkitekturen din, kan ovenstående avvike litt. Forskjellen vil være navnet på mappen etter /usr/lib/gcc. Det viktige å se etter her er det at gcc har funnet alle tre crt*.o filene under /usr/lib mappen.

Bekreft at kompilatoren søker etter riktige deklarasjonsfiler:

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

Denne kommandoen bør returnere følgende utdata:

#include <...> search starts here:
 /usr/lib/gcc/x86_64-pc-linux-gnu/12.2.0/include
 /usr/local/include
 /usr/lib/gcc/x86_64-pc-linux-gnu/12.2.0/include-fixed
 /usr/include

Igjen, mappen oppkalt etter måltripletten kan være annerledes enn de ovennevnte, avhengig av systemarkitekturen.

Deretter bekrefter du at den nye linkeren brukes med de riktige søkebanene:

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

Referanser til stier som har komponenter med '-linux-gnu' bør ignoreres, men ellers bør utdata fra den siste kommandoen være:

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");

Et 32-bits system kan se noen forskjellige mapper. For eksempel her er utdata fra en i686-maskin:

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");

Neste forsikre deg om at vi bruker riktig libc:

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

Utdata fra den siste kommandoen bør være:

attempt to open /usr/lib/libc.so.6 succeeded

Sørg for at GCC bruker riktig dynamisk linker:

grep found dummy.log

Utdataen fra den siste kommandoen bør være (som gir rom for plattformspesifikke forskjeller i dynamisk linkernavn):

found ld-linux-x86-64.so.2 at /usr/lib/ld-linux-x86-64.so.2

Hvis utdataen ikke vises som vist ovenfor eller ikke mottas i det hele tatt, så er det noe alvorlig galt. Undersøk og spor trinn for trinn for å finne ut hvor problemet er og rette det. Eventuelle problemer må løses før du fortsetter med prosessen.

Når alt fungerer som det skal, rydd opp i testfilene:

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

Til slutt flytter du en feilplassert fil:

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