5.10. GCC-9.2.0 - Pass 2

GCC-pakken inneholder GNU-kompilator-samlingen, som inkluderer C- og C ++ -kompilatorene.

 

Omtrentlig byggetid: 13 SBU

Nødvendig diskplass: 3.7 GB


5.10.1. Installasjon av GCC

Vår første bygging av GCC har installert et par interne systemdeklarasjoner. Normalt vil en av dem, limit.h, på sin side inkludere den korresponderende systemen limit.h deklarasjon, i dette tilfellet /tools/include/limits.h. Imidlertid eksisterte ikke denne på tidspunktet for den første bygget av gcc/tools/include/limits.h, så den interne overskriften som GCC installerte er en delvis, selvstendig fil og inkluderer ikke de utvidede funksjonene i systemdeklarasjonen. Dette var tilstrekkelig for å bygge den midlertidige libc, men denne byggingen av GCC krever nå full intern overskrift. Lag en fullversjon av den interne overskriften ved å bruke en kommando som er identisk med hva GCC byggesystemet gjør under normale omstendigheter:

cat gcc/limitx.h gcc/glimits.h gcc/limity.h > \
   `dirname $($LFS_TGT-gcc -print-libgcc-file-name)`/include-fixed/limits.h

Endre nok en gang plasseringen til GCCs standard dynamiske linker for å bruke den som er installert i /tools.

for file in gcc/config/{linux,i386/linux{,64}}.h
do
    cp -uv $file{,.orig}
    sed -e 's@/lib\(64\)\?\(32\)\?/ld@/tools&@g' \
           -e 's@/usr@/tools@g' $file.orig > $file
    echo '
#undef STANDARD_STARTFILE_PREFIX_1
#undef STANDARD_STARTFILE_PREFIX_2
#define STANDARD_STARTFILE_PREFIX_1 "/tools/lib/"
#define STANDARD_STARTFILE_PREFIX_2 ""' >> $file
    touch $file.orig
done

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 den første bygget av GCC krever det GMP-, MPFR- og MPC-pakker. Pakk ut tarballene og flytt dem inn i de nødvendige katalognavnene:

tar -xf ../mpfr-4.0.2.tar.xz
mv -v mpfr-4.0.2 mpfr
tar -xf ../gmp-6.2.0.tar.xz
mv -v gmp-6.2.0 gmp
tar -xf ../mpc-1.1.0.tar.gz
mv -v mpc-1.1.0 mpc

Nå løser du et problem introdusert av Glibc-2.31:

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

Lag en egen byggekatalog igjen:

mkdir -v build
cd build

Før du begynner å bygge GCC, må du huske å fjerne alle miljøvariabler som overstyrer standard optimaliseringsflaggene.

Forbered nå GCC for kompilering:

CC=$LFS_TGT-gcc \
CXX=$LFS_TGT-g++ \
AR=$LFS_TGT-ar \
RANLIB=$LFS_TGT-ranlib \
../configure \
    --prefix=/tools \
    --with-local-prefix=/tools \
    --with-native-system-header-dir=/tools/include \
    --enable-languages=c,c++ \
    --disable-libstdcxx-pch \
    --disable-multilib \
    --disable-bootstrap \
    --disable-libgomp

Betydningen av de nye konfigurasjonsalternativene:

--enable-languages=c,c++
  Dette alternativet sikrer at både C og C ++ kompilatorene er bygget.

--disable-libstdcxx-pch
  Ikke bygg den forhåndskompilerte overskriften (PCH) for libstdc ++. Det tar mye plass, og vi har ingen bruk for det.

--disable-bootstrap
  For lokale bygginger av GCC er standard å gjøre en "bootstrap" build. Dette kompilerer ikke bare GCC, men kompilerer det flere ganger. Den bruker programmene som er samlet i en første runde, for å kompilere seg selv en gang til, og deretter en tredje gang. Den andre og tredje iterasjonen sammenlignes for å sikre at den kan reprodusere seg feilfritt. Dette innebærer også at det ble satt sammen riktig. Imidlertid bør LFS byggemetoden gi en solid kompilator uten behov for å starte opp hver gang.

Kompilere pakken:

make

Installer pakken:

make install

Som en finpuss, lag en symlink. Mange programmer og skript kjører cc i stedet for gcc, som brukes til å holde programmer generiske og derfor brukbare på alle slags UNIX-systemer der GNU C-kompilatoren ikke alltid er installert. Å kjøre cc lar systemadministratoren bestemme hvilken C-kompilator som skal installeres:

ln -sv gcc /tools/bin/cc

På dette tidspunktet er det viktig å stoppe og sikre at de grunnleggende funksjonene (sammenstilling og kobling) av den nye verktøykjeden fungerer som forventet. For å utføre en tilregnelighetskontroll, kjører du følgende kommandoer:

echo 'int main(){}' > dummy.c
cc dummy.c
readelf -l a.out | grep ': /tools'

Hvis alt fungerer som det skal, skal det ikke være noen feil, og utgangen til den siste kommandoen vil være av formen:

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

Merk at for 32-biters maskiner vil tolkens navn være /tools/lib/ld-linux.so.2.

Hvis utgangen ikke vises som ovenfor, eller det ikke var noen utgang i det hele tatt, er noe galt. Først må du utføre sunnhetssjekken igjen, ved å bruke gcc i stedet for cc. Hvis dette fungerer, mangler symlinken /tools/bin/cc. Installer symlinket som ovenfor. Kontroller deretter at PATH er riktig. Dette kan sjekkes ved å kjøre ekko $PATH og bekrefte at /tools/bin står i spissen for listen. Hvis PATH er feil, kan det bety at du ikke er logget inn som bruker lfs, eller at noe gikk galt tilbake i avsnitt 4.4, "Sette opp miljøet."

Når alt er bra, kan du rense opp testfilene:

rm -v dummy.c a.out


Detaljer om denne pakken finnes i kapittel 6.25.2, "Innholdet i GCC."

Forrige Hjem Neste