6.25. GCC-9.2.0

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

 

Omtrentlig byggetid: 88 SBU (med tester)

Nødvendig diskplass: 4.2 GB

6.25.1. Installasjon av GCC

Hvis du bygger på x86_64, endrer du standard katalognavn for 64 bit biblioteker til "lib":

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

Som i gcc pass2, løser du et problem introdusert av Glibc-2.31:

sed -e '1161 s|^|//|' \
       -i libsanitizer/sanitizer_common/sanitizer_platform_limits_posix.cc

GCC dokumentasjonen anbefaler å bygge GCC i en dedikert byggemappe:

mkdir -v build
cd build

Forbered GCC for kompilering:

SED=sed \
../configure --prefix=/usr \
                     --enable-languages=c,c++ \
                     --disable-multilib \
                     --disable-bootstrap \
                     --with-system-zlib

Merk at for andre språk er det noen forutsetninger som ennå ikke er tilgjengelige. Se BLFS boken for instruksjoner om hvordan du bygger alle GCCs støttede språk.

Betydningen av de nye konfigurasjonsalternativene:

SED=sed
    Innstilling av denne miljøvariabelen forhindrer en hardkodet bane til /tools/bin/sed.

--with-system-zlib
   Denne bryteren ber GCC om å koble til den installerte kopien av Zlib-biblioteket, i stedet for sin egen interne kopi.

Kompilere pakken:

make

Testserien for GCC i denne delen anses som kritisk. Ikke hopp over den under noen omstendigheter.

Et sett med tester i GCC testpakken er kjent for å anstrenge stabelen (stacken), så øk stabelstørrelsen før du kjører testene:

ulimit -s 32768

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

chown -Rv nobody .
su nobody -s /bin/bash -c "PATH=$PATH make -k check"

Hvis du vil motta et sammendrag av resultatene av testserien, kjører du:

../contrib/test_summary

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

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

Seks tester relatert til get_time er kjent for å mislykkes. Disse er tilsynelatende relatert til en_HK regionaldataen.

To tester kalt lookup.cc og reverse.cc i experimental/net er kjent for å mislykkes i LFS chroot-miljø fordi de krever /etc/hosts og iana-etc.

To tester kalt pr57193.c og pr90178.c er kjent for å mislykkes.

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 veldig forskjellige fra URLene over, er det trygt å fortsette.

Installer pakken og fjern en unødvendig mapper:

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

GCC byggemappe eies nå av nobody, og eierforholdet til den installerte deklarasjonen (og dens innhold) vil være feil. Endre eierforhold til root bruker og gruppe:

chown -v -R root:root \
          /usr/lib/gcc/*linux-gnu/9.2.0/include{,-fixed}

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

Mange pakker bruker navnet cc for å kalle C kompilatoren. For å tilfredsstille disse pakkene, oppretter du en symlink:

ln -sv gcc /usr/bin/cc

Legg til en kompatibilitetssymlink for å aktivere byggeprogrammer med Link Time Optimization (LTO):

install -v -dm755 /usr/lib/bfd-plugins
ln -sfv ../../libexec/gcc/$(gcc -dumpmachine)/9.2.0/liblto_plugin.so \
           /usr/lib/bfd-plugins/

Nå som den endelige verktøykjeden vår er på plass, er det viktig å igjen sikre at kompilering og kobling fungerer som forventet. Dette gjør vi ved å utføre de samme fornuftskontrollene som vi gjorde tidligere i kapitlet:

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 utdataene fra den siste kommandoen vil være (det kan være plattformspesifikke forskjeller i dynamisk linker navn):

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

Forsikre deg nå om at vi er klar til å bruke de riktige startfilene:

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

Utdataen til den siste kommandoen skal være:

/usr/lib/gcc/x86_64-pc-linux-gnu/9.2.0/../../../../lib/crt1.o succeeded
/usr/lib/gcc/x86_64-pc-linux-gnu/9.2.0/../../../../lib/crti.o succeeded
/usr/lib/gcc/x86_64-pc-linux-gnu/9.2.0/../../../../lib/crtn.o succeeded

Avhengig av maskinarkitekturen, kan ovennevnte avvike noe, forskjellen er vanligvis navnet på katalogen etter /usr/lib/gcc. Det viktige å se etter her er at gcc har funnet alle tre crt * .o-filer under /usr/lib mappen.

Kontroller at kompilatoren søker etter riktige deklarasjoner:

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/9.2.0/include
/usr/local/include
/usr/lib/gcc/x86_64-pc-linux-gnu/9.2.0/include-fixed
/usr/include

Legg igjen merke til at katalogen som er oppkalt etter måltripletten din, kan være annerledes enn ovenfor, avhengig av arkitekturen.

Deretter må du bekrefte at den nye linkeren brukes med de riktige søkeveiene:

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 biters system kan se noen få forskjellige kataloger. Her er for eksempel utgangen 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 sørg for at vi bruker riktig libc:

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

Utdataen til den siste kommandoen skal være:

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

Til slutt, sørg for at GCC bruker riktige dynamisk linker:

grep found dummy.log

Utdataen fra den siste kommandoen skal være (det kan være plattformspesifikke forskjeller i dynamisk linkernavn):

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

Hvis utgangen ikke vises som vist ovenfor eller ikke mottas i det hele tatt, er noe alvorlig galt. Undersøk og følg trinnene for å finne ut hvor problemet er og rette det. Den mest sannsynlige årsaken er at noe gikk galt med specs filjustering. Eventuelle problemer må løses før du fortsetter med prosessen.

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

Når alt fungerer riktig, slett 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

6.25.2. Innholdet i GCC

Installerte programmer: c++, cc (lenke til gcc), cpp, g++, gcc, gcc-ar, gcc-nm, gcc-ranlib, gcov, gcov-dump, og gcov-tool

Installerte biblioteker: libasan.{a,so}, libatomic.{a,so}, libcc1.so, libgcc.a, libgcc_eh.a, libgcc_s.so, libgcov.a, libgomp.{a,so}, libitm.{a,so}, liblsan.{a,so}, liblto_plugin.so, libquadmath.{a,so}, libssp.{a,so}, libssp_nonshared.a, libstdc++.{a,so}, 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-9.2.0

 

Kort beskrivelse

c++ - C++ kompilatoren

cc - C kompilatoren

cpp - C forbehandler; den brukes av kompilatoren til å utvide #include, #define og lignende utsagn i kildefilene

g++ - C++ kompilatoren

gcc - C kompilatoren

gcc-ar - En wrapper rundt ar som legger et programtillegg til kommandolinjen. Dette programmet brukes bare til å legge til "optimalisering av koblingstid" og er ikke nyttig med standardbyggealternativene

gcc-nm - En wrapper rundt nm som legger et programtillegg til kommandolinjen. Dette programmet brukes bare til å legge til "optimalisering av koblingstid" og er ikke nyttig med standardbyggealternativene

gcc-ranlib - En wrapper rundt ranlib som legger et programtillegg til kommandolinjen. Dette programmet brukes bare til å legge til "optimalisering av koblingstid" og er ikke nyttig med standardbyggealternativene

gcov - Et verktøy for dekningstesting; den brukes til å analysere programmer for å bestemme hvor optimaliseringer vil ha mest effekt

gcov-dump - Frakoblet gcda og gcno profildumpverktøy

gcov-tool - Frakoblet gcda profilbehandlingsverktøy

libasan - Adresset rensing kjøretidsbibliotek

libatomic - GCC atomic innebygde kjøretidsbibliotek

libcc1 - C forbehandlingsbiblioteket

libgcc - Inneholder støtte for kjøretid for gcc

libgcov - Dette biblioteket er koblet til et program når GCC blir instruert om å muliggjøre profilering

libgomp - GNU implementering av OpenMP API for parallellprogrammering med delt plattform i flere plattformer i C/C++ og Fortran

liblsan - Kjøretidsbibliotek for lekkasjerensing

liblto_plugin - GCCs Link Time Optimization (LTO) programtillegg gjør det mulig for GCC å utføre optimaliseringer på tvers av samlingsenheter

libquadmath - GCC Quad Matte presisjonsbibliotek API

libssp - Inneholder rutiner som støtter GCCs stack-smashing beskyttelsesfunksjonalitet

libstdc++ - Standard C++ bibliotek

libstdc++fs - ISO/IEC TS 18822:2015 Filsystembibliotek

libsupc++ - Tilbyr støtterutiner for programmeringsspråket C++

libtsan - Kjøretidsbibliotek for trådrenser 

libubsan - Det udefinerte kjøretidsbiblioteket for adfersrenser 

Forrige Hjem Neste