5.2. Tekniske merknader for verktøykjede

Denne delen forklarer noen av begrunnelsene og tekniske detaljene bak den generelle byggmetoden. Det er ikke viktig å umiddelbart forstå alt i dette avsnittet. Det meste av denne informasjonen vil være tydeligere etter å ha utført et faktisk bygg. Denne delen kan bli vist til når som helst under prosessen.

Det overordnede målet med kapittel 5 er å produsere et midlertidig område som inneholder et kjent godt sett med verktøy som kan isoleres fra vertssystemet. Ved å bruke chroot, vil kommandoene i de gjenværende kapitlene være inne i det miljøet, noe som sikrer en ren, problemfri bygging av LFS systemet. Byggeprosessen er designet for å minimere risikoen for nye lesere og samtidig gi mest mulig pedagogisk verdi.

Før du fortsetter, må du være oppmerksom på navnet på arbeidsplattformen, ofte referert til som mål triplett. En enkel måte å bestemme navnet på mål tripletten er å kjøre config.guess-skriptet som følger med kilden for mange pakker. Pakk ut Binutils-kildene og kjør skriptet: ./config.guess og noter output. For en 32-biters Intel-prosessor vil for eksempel utgangen være i686-pc-linux-gnu. På et 64-biters system vil det være x86_64-pc-linux-gnu.

Vær også oppmerksom på navnet på plattformens dynamiske linker, ofte referert til som den dynamiske lasteren (for ikke å forveksle med standard linker ld som er en del av Binutils). Den dynamiske linkeren levert av Glibc finner og laster de delte bibliotekene som trengs av et program, forbereder programmet til å kjøre og kjører det deretter. Navnet på den dynamiske linkeren for en 32-bit Intel-maskin vil være ld-linux.so.2 (ld-linux-x86-64.so.2 for 64-biters systemer). En sikker måte å bestemme navnet på den dynamiske linkeren er å inspisere en tilfeldig binær fra vertssystemet ved å kjøre: readelf -l <name of binary> | grep interpreter tolk og noterer output. Den autoritative referansen som dekker alle plattformer, er i filen shlib-versjoner i roten til Glibc kildetre.

Noen viktige tekniske punkter for hvordan kapittel 5-byggemetoden fungerer:

  • Ved å justere navnet på arbeidsplattformen ved å endre "leverandøren" feltet mål triplett ved hjelp av LFS_TGT-variabelen, sikrer du at den første byggingen av Binutils og GCC produserer en kompatibel tverrlinker og tverrkompilator. I stedet for å produsere binære filer for en annen arkitektur, vil tverrlinkeren og tverrkompilatoren produsere binære filer som er kompatible med den nåværende maskinvaren.
  • De midlertidige bibliotekene er tverrkompilert. Fordi en tverrkompilator i sin natur ikke kan stole på noe fra vertssystemet, fjerner denne metoden potensiell forurensning av målsystemet ved å redusere sjansen for at overskrifter eller biblioteker fra verten blir inkorporert i de nye verktøyene. Kryss-kompilering gir også muligheten for å bygge både 32-biters og 64-biters biblioteker på 64-biters maskinvare.
  • Nøye manipulering av GCC-kilden forteller kompilatoren hvilket dynamisk linker vil bli brukt.

Binutils installeres først fordi konfigurasjonsløpene for både GCC og Glibc utfører forskjellige funksjonstester på assembleren og linkeren for å bestemme hvilke programvarefunksjoner som skal aktiveres eller deaktiveres. Dette er viktigere enn man først kan innse. En feil konfigurert GCC eller Glibc kan resultere i en subtilt ødelagt verktøykjede, der virkningen av slikt brudd kanskje ikke dukker opp før nær slutten av byggingen av en hel distribusjon. En testsuksess vil vanligvis utheve denne feilen før det utføres for mye tilleggsarbeid.

Binutils installerer assembleren og linkeren på to steder, /tools/bin og /tools/$LFS_TGT/bin. Verktøyene på det ene stedet er vanskelig knyttet til det andre. En viktig fasit for linkeren er bibliotekets søkerekkefølge. Detaljert informasjon kan fås fra ld ved å sende det --verbose flagget. For eksempel en ld - verbose | grep SEARCH vil illustrere de gjeldende søkeveiene og deres rekkefølge. Den viser hvilke filer som er lenket av ld ved å kompilere et dummy-program og sende --verbose-bryteren til linkeren. For eksempel gcc dummy.c -Wl, - verbose 2> & 1 | grep succeeded vil vise alle filene som ble vellykket åpnet under koblingen.

Den neste pakken som er installert er GCC. Et eksempel på hva som kan sees i løpet av konfigurasjonen er:

checking what assembler to use... /tools/i686-lfs-linux-gnu/bin/as
checking what linker to use... /tools/i686-lfs-linux-gnu/bin/ld

Dette er viktig av grunnene nevnt ovenfor. Det viser også at GCCs konfigurasjonsskript ikke søker i PATH-katalogene for å finne hvilke verktøy du vil bruke. Imidlertid brukes ikke nødvendigvis de samme søkeveiene under selve driften av selve gcc. For å finne ut hvilken standard linker gcc vil bruke, kjør: gcc -print-prog-name = ld.

Detaljert informasjon kan fås fra gcc ved å sende det -v kommandolinjealternativet mens du sammenstiller et dummy-program. For eksempel vil gcc -v dummy.c vise detaljert informasjon om forbehandler, kompilering og monteringstrinn, inkludert gcc inkluderte søkeveier og deres rekkefølge.

Neste å installere er en ren Linux API headers. Disse lar standard C-biblioteket (Glibc) samhandle mot funksjoner som Linux-kjernen vil gi.

Den neste pakken som er installert er Glibc. De viktigste betraktningene for å bygge Glibc er kompilatoren, binære verktøy og kjerneoverskrifter. Kompilatoren er vanligvis ikke et problem, siden Glibc alltid vil bruke kompilatoren relatert til - host-parameteren som er sendt til konfigurasjonsskriptet; f.eks i vårt tilfelle vil kompilatoren være i686-lfs-linux-gnu-gcc. De binære verktøyene og kjerneoverskriftene kan være litt mer kompliserte. Ta derfor ingen risiko og bruk de tilgjengelige konfigurasjonsbryterne for å håndheve de riktige valgene. Etter konfigureringskjøringen, sjekk innholdet i config.make-filen i glibc-build-katalogen for alle viktige detaljer. Legg merke til bruken av CC = "i686-lfs-gnu-gcc" for å kontrollere hvilke binære verktøy som brukes, og bruken av -nostdinc og -system-flaggene for å kontrollere kompilatorens inkluderte søkebane. Disse varene fremhever et viktig aspekt av Glibc-pakken - den er veldig selvforsynt med tanke på byggmaskineriet og stoler generelt ikke på standardverktøyets standardverdier.

I løpet av den andre passering av Binutils er vi i stand til å bruke - with-lib-path-konfigurasjonsbryteren til å kontrollere ld's biblioteksøkingssti.

For den andre passering av GCC, må kildene også modifiseres for å fortelle GCC om å bruke den nye dynamiske linkeren. Unnlatelse av å gjøre dette vil resultere i at GCC-programmene selv har navnet på den dynamiske linkeren fra vertssystemets /lib-katalogen innebygd i dem, noe som vil beseire målet om å komme vekk fra verten. Fra dette tidspunktet er kjerneverktøykjeden selvforsynt og selv vert. Resten av kapittel 5-pakkene bygger alle mot den nye Glibc in /tools.

Når du kommer inn i chroot-miljøet i kapittel 6, er den første store pakken som er installert Glibc, på grunn av dens selvforsynt natur nevnt ovenfor. Når denne Glibc er installert i /usr, vil vi utføre en rask omstilling av standardverktøyene til verktøykjeden og deretter fortsette med å bygge resten av LFS-systemet.

Forrige Hjem Neste