Linux From Scratch - Versjon 12.1

Chapter 8. Installere grunnleggende systemprogramvare

8.28. GCC-13.2.0

GCC pakken inneholder GNU kompilatorsamlingen, som inkluderer C og C++ kompilatorene.

Omtrentlig byggetid: 42 SBU (med testene)
Nødvendig diskplass: 5.5 GB

8.28.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      \
             --disable-fixincludes    \
             --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.

Betydningen av de nye konfigureringsparametrene:

LD=ld

Denne parameteren gjør at konfigureringsskriptet bruker ld installert av binutils bygget tidligere i dette kapittelet, i stedet for den kryssbygde versjonen som ellers ville blitt brukt.

--disable-fixincludes

Som standard, under installasjonen av GCC noen systemdeklarasjoner vil være “låst” for bruk med GCC. Dette er ikke nødvendig for et moderne Linuxsystem, og potensielt skadelig hvis en pakke installeres på nytt etter installasjon av GCC. Denne bryteren hindrer GCC fra å “låse” deklarasjonene.

--with-system-zlib

Denne bryteren forteller GCC å koble til den systeminstallerte kopien av zlib biblioteket, i stedet for sin egen interne kopi.

[Note]

Note

PIE (position independent executable) er en teknikk for å produsere binære programmer som kan lastes hvor som helst i minnet. Uten PIE, sikkerhetsfunksjonen kalt ASLR (Address Space Layout Randomization) kan legges til for de delte bibliotekene, men ikke de kjørbare filen. Aktivering av PIE tillater ASLR for de kjørbare filene i tillegg til de delte bibliotekene, og reduserer noen angrep basert på faste adresser til sensitiv kode eller data i de kjørbare filene.

SSP (Stack Smashing Protection) er en teknikk for å sikre at parameterstabelen ikke er ødelagt. Stabelkorrupsjon kan for eksempel endre returadressen til en subrutine, som ville tillate overføring av kontroll til en eller annen farlig kode (som eksisterer i programmet eller delte biblioteker, eller injisert av en angriper på en eller annen måte) i stedet for den originale.

Kompiler pakken: 

make
[Important]

Important

I denne delen vurderes testpakken for GCC å være viktig, men det tar lang tid. Førstegangsbyggere oppfordres til ikke å hoppe over dette. Tiden for å kjøre testene kan bli redusert betydelig ved å legge til -jx til make -k check kommandoen nedenfor hvor x er antall kjerner på systemet ditt.

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 -R 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/12.1/ og https://gcc.gnu.org/ml/gcc-testresults/.

Åtte gcc tester (av over 185 000): pr56837.c og syv tester i analyzer mappen er kjent for å mislykkes. En libstdc++ test (av over 15000), copy.cc, er kjent for å mislykkes. For g++, 21 tester (ut av omtrentlig 250,000): 14 “AddressSanitizer*” tester og 7 interception-malloc-test-1.C tester, er kjent for å mislykkes. I tillegg flere tester i vect mappen er kjent for å mislykkes hvis maskinvaren ikke støtter AVX.

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)/13.2.0/include{,-fixed}

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

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

Mange pakker bruker navnet cc for å kalle C kompilatoren. Vi har allerede opprettet cc som en symlenke i gcc-pass2, opprette mansiden til den som en symbolkobling også 

ln -sv gcc.1 /usr/share/man/man1/cc.1

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

ln -sfv ../../libexec/gcc/$(gcc -dumpmachine)/13.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/13.2.0/../../../../lib/Scrt1.o succeeded
/usr/lib/gcc/x86_64-pc-linux-gnu/13.2.0/../../../../lib/crti.o succeeded
/usr/lib/gcc/x86_64-pc-linux-gnu/13.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/13.2.0/include
 /usr/local/include
 /usr/lib/gcc/x86_64-pc-linux-gnu/13.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

8.28.2. Innhold i GCC

Installerte programmer: c++, cc (link to gcc), cpp, g++, gcc, gcc-ar, gcc-nm, gcc-ranlib, gcov, gcov-dump, gcov-tool, og lto-dump
Installerte biblioteker: libasan.{a,so}, libatomic.{a,so}, libcc1.so, libgcc.a, libgcc_eh.a, libgcc_s.so, libgcov.a, libgomp.{a,so}, libhwasan.{a,so}, libitm.{a,so}, liblsan.{a,so}, liblto_plugin.so, libquadmath.{a,so}, libssp.{a,so}, libssp_nonshared.a, libstdc++.{a,so}, libstdc++exp.a, libstdc++fs.a, libsupc++.a, libtsan.{a,so}, og libubsan.{a,so}
Installerte mapper: /usr/include/c++, /usr/lib/gcc, /usr/libexec/gcc, og /usr/share/gcc-13.2.0

Korte beskrivelser

c++

C++ kompilatoren

cc

C kompilatoren

cpp

C forprosessoren; den brukes av kompilatoren for å utvide #include, #define og lignende utsagn i kildefilene

g++

C++ kompilatoren

gcc

C kompilatoren

gcc-ar

En innpakning rundt ar som legger til et programtillegg til kommandolinjen. Dette programmet brukes kun for å legge til "koblingstidsoptimalisering (link time optimization)" og er ikke nyttig med standard byggealternativer

gcc-nm

En innpakning rundt nm som legger til et programtillegg til kommandolinjen. Dette programmet brukes kun for å legge til "koblingstidsoptimalisering (link time optimization)" og er ikke nyttig med standard byggealternativer

gcc-ranlib

En innpakning rundt ranlib som legger til et programtillegg til kommandolinjen. Dette programmet brukes kun for å legge til "koblingstidsoptimalisering (link time optimization)" og er ikke nyttig med standard byggealternativer

gcov

Et dekningstestverktøy; den brukes til å analysere programmer å bestemme hvor optimaliseringer vil ha størst effekt

gcov-dump

Frakoblet (offline) gcda og gcno profildumpverktøy

gcov-tool

Frakoblet (offline) gcda profilbehandlingsverktøy

lto-dump

Verktøy for dumping av objektfiler produsert av GCC med LTO aktivert

libasan

Kjøretidsbiblioteket for adresserensing

libatomic

GCC atomic innebygde kjøretidsbibliotek

libcc1

Et bibliotek som lar GDB bruke GCC

libgcc

Inneholder kjøretidsstøtte for gcc

libgcov

Dette biblioteket er koblet inn i et program når GCC blir instruert om å aktivere profilering

libgomp

GNU implementering av OpenMP API for multiplattform parallellprogrammering med delt minne i C/C++ og Fortran

libhwasan

Maskinvareassistert kjøretidsbibliotek for Adresserensing

libitm

GNU transaksjonsminnebiblioteket

liblsan

Leak Sanitizer kjøretidsbibliotek

liblto_plugin

GCC sitt LTO programtillegg som lar binutils behandle objektfiler produsert av GCC med LTO aktivert

libquadmath

GCC Quad Precision Math Library API

libssp

Inneholder rutiner som støtter GCCs stabelknusende beskyttelsesfunksjonalitet. Normalt er det ubrukt fordi glibc også gir disse rutinene

libstdc++

Standard C++ biblioteket

libstdc++exp

Eksperimentelt C++ kontraktsbibliotek

libstdc++fs

ISO/IEC TS 18822:2015 filsystembibliotek

libsupc++

Gir støttende rutiner for C++ programmeringsspråk

libtsan

Thread Sanitizer kjøretidsbibliotek

libubsan

Undefined Behavior Sanitizer kjøretidsbibliotek