8.26. GCC-12.2.0

8.26.1. Installasjon av GCC

Hvis du bygger på x86_64, endre standard katalognavn 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++ \
             --disable-multilib       \
             --disable-bootstrap      \
             --with-system-zlib

Merk at for andre programmeringsspråk er det noen forutsetninger som ikke er tilgjengelig 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"

To receive a summary of the test suite results, run:

../contrib/test_summary

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

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

I g++ er det kjent at fire tester relatert til PR100400 er rapportert som både XPASS og FAIL. Det er fordi testfilen for dette kjente problemet ikke er 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 byggekatalogen 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):

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 skal ikke være noen feil, og utgangen 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]

Forsikre deg om at det er konfigurert til å bruke de riktige startfilene:

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

Utdata fra den siste kommandoen skal være:

/usr/lib/gcc/x86_64-pc-linux-gnu/12.2.0/../../../../lib/crt1.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 riktig deklarasjonsfil:

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

Denne kommandoen skal 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 skal 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 kataloger. 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");

Forsikre deg om at vi bruker riktig libc:

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

Utdata fra den siste kommandoen skal være:

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

Sørg for at GCC bruker riktig dynamisk linker:

grep found dummy.log

Utgangen fra den siste kommandoen skal 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