Stații de lucru online OnWorks Linux și Windows

logo

Găzduire online gratuită pentru stații de lucru

<Înapoi | Cuprins | Următor>

5.2. Note tehnice pentru lanțul de instrumente‌

Această secțiune explică unele dintre motivele și detaliile tehnice din spatele metodei generale de construire. Nu este esențial să înțelegeți imediat totul în această secțiune. Cele mai multe dintre aceste informații vor fi mai clare după efectuarea unei realizări reale. Se poate face referire la această secțiune în orice moment în timpul procesului.

imagine

Scopul general al Capitolului 5 este de a produce o zonă temporară care conține un set de instrumente bine cunoscute care pot fi izolate de sistemul gazdă. Prin utilizarea Chroot., comenzile din capitolele rămase vor fi conținute în acel mediu, asigurând o construcție curată și fără probleme a sistemului LFS țintă. Procesul de compilare a fost conceput pentru a minimiza riscurile pentru cititorii noi și pentru a oferi cea mai bună valoare educațională în același timp.


notițe

Înainte de a continua, fiți conștienți de numele platformei de lucru, adesea denumită triplet țintă. O modalitate simplă de a determina numele tripletului țintă este să rulați config.ghici script care vine cu sursa pentru multe pachete. Despachetați sursele Binutils și rulați scriptul: ./config.ghici și notează rezultatul. De exemplu, pentru un procesor Intel pe 32 de biți ieșirea va fi i686-pc-linux-gnu. Pe un sistem pe 64 de biți va fi x86_64-pc-linux-gnu.

De asemenea, fiți conștienți de numele linkerului dinamic al platformei, adesea denumit încărcătorul dinamic (a nu se confunda cu linkerul standard ld care face parte din Binutils). Linkerul dinamic furnizat de Glibc găsește și încarcă bibliotecile partajate necesare unui program, pregătește programul pentru a rula și apoi îl rulează. Numele linkerului dinamic pentru o mașină Intel pe 32 de biți va fi ld-linux.so.2 (ld-linux-x86-64.so.2 pentru sisteme pe 64 de biți). O modalitate sigură de a determina numele linkerului dinamic este să inspectați un binar aleator din sistemul gazdă, rulând: readelf -l | interpret grep și notând rezultatul. Referința cu autoritate care acoperă toate platformele este în versiuni shlib fișier în rădăcina arborelui sursă Glibc.

notițe

Înainte de a continua, fiți conștienți de numele platformei de lucru, adesea denumită triplet țintă. O modalitate simplă de a determina numele tripletului țintă este să rulați config.ghici script care vine cu sursa pentru multe pachete. Despachetați sursele Binutils și rulați scriptul: ./config.ghici și notează rezultatul. De exemplu, pentru un procesor Intel pe 32 de biți ieșirea va fi i686-pc-linux-gnu. Pe un sistem pe 64 de biți va fi x86_64-pc-linux-gnu.

De asemenea, fiți conștienți de numele linkerului dinamic al platformei, adesea denumit încărcătorul dinamic (a nu se confunda cu linkerul standard ld care face parte din Binutils). Linkerul dinamic furnizat de Glibc găsește și încarcă bibliotecile partajate necesare unui program, pregătește programul pentru a rula și apoi îl rulează. Numele linkerului dinamic pentru o mașină Intel pe 32 de biți va fi ld-linux.so.2 (ld-linux-x86-64.so.2 pentru sisteme pe 64 de biți). O modalitate sigură de a determina numele linkerului dinamic este să inspectați un binar aleator din sistemul gazdă, rulând: readelf -l | interpret grep și notând rezultatul. Referința cu autoritate care acoperă toate platformele este în versiuni shlib fișier în rădăcina arborelui sursă Glibc.

Câteva puncte tehnice cheie ale modului în care funcționează metoda de construire a capitolului 5:

• Ajustarea ușoară a numelui platformei de lucru, prin schimbarea tripletului țintă de câmp „furnizor” prin intermediul LFS_TGT variabilă, asigură că prima versiune a Binutils și GCC produce un cross-linker și un cross-compilator compatibil. În loc să producă binare pentru o altă arhitectură, reticulatorul și compilatorul încrucișat vor produce binare compatibile cu hardware-ul actual.


• Bibliotecile temporare sunt compilate încrucișat. Deoarece un compilator încrucișat, prin natura sa, nu se poate baza pe nimic din sistemul său gazdă, această metodă înlătură potențiala contaminare a sistemului țintă prin reducerea șanselor ca anteturile sau bibliotecile de la gazdă să fie încorporate în noile instrumente. Compilarea încrucișată permite, de asemenea, posibilitatea de a construi biblioteci atât pe 32 de biți, cât și pe 64 de biți pe hardware compatibil pe 64 de biți.

• Manipularea atentă a sursei GCC spune compilatorului care linker dinamic țintă va fi folosit.

Binutils este instalat mai întâi deoarece configura rulările atât ale GCC, cât și ale Glibc efectuează diverse teste de caracteristici pe asamblator și linker pentru a determina ce caracteristici software să activeze sau să dezactiveze. Acest lucru este mai important decât s-ar putea realiza la început. Un GCC sau Glibc configurat incorect poate duce la un lanț de instrumente rupt subtil, în care impactul unei astfel de spargeri ar putea să nu apară până aproape de sfârșitul construcției unei întregi distribuții. Un eșec al suitei de testare va evidenția de obicei această eroare înainte de a se efectua prea multă muncă suplimentară.

Binutils își instalează asamblatorul și linkerul în două locații, /tools/bin și /tools/$LFS_TGT/bin. Instrumentele dintr-o locație sunt greu legate de cealaltă. O fațetă importantă a linkerului este ordinea de căutare în bibliotecă. Informații detaliate pot fi obținute de la ld prin trecerea lui --verbos steag. De exemplu, un ld --verbos | CĂUTARE grep va ilustra căile de căutare curente și ordinea acestora. Acesta arată prin ce fișiere sunt legate ld prin compilarea unui program inactiv și prin trecerea --verbos comutați la linker. De exemplu, gcc dummy.c -Wl,--verbose 2>&1

| grep succeeded va afișa toate fișierele deschise cu succes în timpul conectării.

Următorul pachet instalat este GCC. Un exemplu de ceea ce poate fi văzut în timpul rulării sale configura este:


se verifică ce asamblator să folosească... /tools/i686-lfs-linux-gnu/bin/as se verifică ce linker să folosească... /tools/i686-lfs-linux-gnu/bin/ld

se verifică ce asamblator să folosească... /tools/i686-lfs-linux-gnu/bin/as se verifică ce linker să folosească... /tools/i686-lfs-linux-gnu/bin/ld

Acest lucru este important din motivele menționate mai sus. De asemenea, demonstrează că scriptul de configurare al GCC nu caută în directoarele PATH pentru a găsi ce instrumente să folosească. Cu toate acestea, în timpul funcționării efective a gcc în sine, aceleași căi de căutare nu sunt neapărat utilizate. Pentru a afla ce linker standard gcc va folosi, rula: gcc -print-prog-name=ld.

Informații detaliate pot fi obținute de la gcc prin trecerea lui -v opțiunea de linie de comandă în timp ce compilați un program fals. De exemplu, gcc -v manechin.c va afișa informații detaliate despre fazele de preprocesor, compilare și asamblare, inclusiv gccau inclus căile de căutare și ordinea acestora.

Următorul instalat sunt anteturile API Linux dezinfectate. Acestea permit bibliotecii standard C (Glibc) să interfațeze cu caracteristicile pe care le va furniza nucleul Linux.

Următorul pachet instalat este Glibc. Cele mai importante considerații pentru construirea Glibc sunt compilatorul, instrumentele binare și anteturile kernelului. Compilatorul nu este, în general, o problemă, deoarece Glibc va folosi întotdeauna compilatorul referitor la --gazdă parametrul trecut la scriptul său de configurare; de exemplu, în cazul nostru, compilatorul va fi i686-lfs-linux-gnu-gcc. Instrumentele binare și anteturile nucleului pot fi puțin mai complicate. Prin urmare, nu vă asumați riscuri și utilizați comutatoarele de configurare disponibile pentru a impune selecțiile corecte. După fuga de configura, verificați conținutul config.face de fișier în glibc-build director pentru toate detaliile importante. Observați utilizarea CC="i686-lfs-gnu-gcc" pentru a controla ce instrumente binare sunt utilizate și utilizarea -nostdinc și -isistem steaguri pentru a controla calea de căutare include a compilatorului. Aceste articole evidențiază un aspect important al pachetului Glibc - este foarte autosuficient în ceea ce privește mașinile sale de construcție și, în general, nu se bazează pe setările implicite ale lanțului de instrumente.

În timpul celei de-a doua treceri a Binutils, putem folosi --with-lib-path configurați comutatorul pentru control ldcalea de căutare a bibliotecii lui.

Pentru a doua trecere a GCC, sursele sale trebuie, de asemenea, modificate pentru a spune GCC să folosească noul linker dinamic. În caz contrar, programele GCC vor avea numele linkerului dinamic din sistemul gazdă. / lib director încorporat în ele, ceea ce ar învinge obiectivul de a scăpa de gazdă. Din acest punct încolo, lanțul de instrumente de bază este autonom și găzduit. Restul pachetelor din Capitolul 5 sunt construite împotriva noului Glibc în /instrumente.


La intrarea în mediul chroot în Capitolul 6, primul pachet major instalat este Glibc, datorită naturii sale autosuficiente menționate mai sus. Odată ce acest Glibc este instalat în / usr, vom efectua o schimbare rapidă a setărilor implicite ale lanțului de instrumente, apoi vom continua la construirea restului sistemului LFS țintă.


Top OS Cloud Computing la OnWorks: