Documentatie5.2. Technische opmerkingen over de toolchain
In dit gedeelte worden enkele van de grondgedachte en technische details achter de algemene bouwmethode uitgelegd. Het is niet essentieel om alles in dit gedeelte meteen te begrijpen. De meeste van deze informatie zal duidelijker zijn na het uitvoeren van een daadwerkelijke build. Dit gedeelte kan op elk moment tijdens het proces worden geraadpleegd.
Het algemene doel van hoofdstuk 5 is om een tijdelijk gebied te creëren dat een set tools bevat waarvan bekend is dat ze goed zijn en die van het hostsysteem kunnen worden geïsoleerd. Door het gebruiken van chroot, zullen de opdrachten in de overige hoofdstukken in die omgeving worden opgenomen, waardoor een schone, probleemloze opbouw van het doel-LFS-systeem wordt gegarandeerd. Het bouwproces is ontworpen om de risico's voor nieuwe lezers te minimaliseren en tegelijkertijd de meeste educatieve waarde te bieden.
Note
Voordat u verdergaat, moet u op de hoogte zijn van de naam van het werkplatform, ook wel het doeltriplet genoemd. Een eenvoudige manier om de naam van het doeltriplet te bepalen, is door het programma uit te voeren config.gok script dat bij de broncode van veel pakketten wordt geleverd. Pak de Binutils-bronnen uit en voer het script uit: ./config.raad en noteer de uitvoer. Voor een 32-bits Intel-processor zal de uitvoer bijvoorbeeld zijn i686-pc-linux-gnu. Op een 64-bit systeem zal dat wel het geval zijn x86_64-pc-linux-gnu.
Houd ook rekening met de naam van de dynamische linker van het platform, vaak de dynamische lader genoemd (niet te verwarren met de standaard linker ld dat is onderdeel van Binutils). De dynamische linker van Glibc vindt en laadt de gedeelde bibliotheken die een programma nodig heeft, bereidt het programma voor om te worden uitgevoerd en voert het vervolgens uit. De naam van de dynamische linker voor een 32-bits Intel-machine zal zijn ld-linux.so.2 (ld-linux-x86-64.so.2 voor 64-bits systemen). Een betrouwbare manier om de naam van de dynamische linker te bepalen, is door een willekeurig binair bestand van het hostsysteem te inspecteren door het volgende uit te voeren: leeself -l | grep-tolk en het noteren van de output. De gezaghebbende referentie voor alle platforms staat in de shlib-versies bestand in de hoofdmap van de Glibc-bronboom.
Note
Voordat u verdergaat, moet u op de hoogte zijn van de naam van het werkplatform, ook wel het doeltriplet genoemd. Een eenvoudige manier om de naam van het doeltriplet te bepalen, is door het programma uit te voeren config.gok script dat bij de broncode van veel pakketten wordt geleverd. Pak de Binutils-bronnen uit en voer het script uit: ./config.raad en noteer de uitvoer. Voor een 32-bits Intel-processor zal de uitvoer bijvoorbeeld zijn i686-pc-linux-gnu. Op een 64-bit systeem zal dat wel het geval zijn x86_64-pc-linux-gnu.
Houd ook rekening met de naam van de dynamische linker van het platform, vaak de dynamische lader genoemd (niet te verwarren met de standaard linker ld dat is onderdeel van Binutils). De dynamische linker van Glibc vindt en laadt de gedeelde bibliotheken die een programma nodig heeft, bereidt het programma voor om te worden uitgevoerd en voert het vervolgens uit. De naam van de dynamische linker voor een 32-bits Intel-machine zal zijn ld-linux.so.2 (ld-linux-x86-64.so.2 voor 64-bits systemen). Een betrouwbare manier om de naam van de dynamische linker te bepalen, is door een willekeurig binair bestand van het hostsysteem te inspecteren door het volgende uit te voeren: leeself -l | grep-tolk en het noteren van de output. De gezaghebbende referentie voor alle platforms staat in de shlib-versies bestand in de hoofdmap van de Glibc-bronboom.
Enkele belangrijke technische punten over hoe de bouwmethode van Hoofdstuk 5 werkt:
• De naam van het werkplatform enigszins aanpassen, door het doeltriplet "leverancier" te wijzigen via de LFS_TGT variabele, zorgt ervoor dat de eerste build van Binutils en GCC een compatibele cross-linker en cross-compiler produceert. In plaats van binaire bestanden te produceren voor een andere architectuur, zullen de crosslinker en cross-compiler binaire bestanden produceren die compatibel zijn met de huidige hardware.
• De tijdelijke bibliotheken zijn kruiscompileerbaar. Omdat een cross-compiler van nature niet op iets van zijn hostsysteem kan vertrouwen, elimineert deze methode potentiële besmetting van het doelsysteem door de kans te verkleinen dat headers of bibliotheken van de host in de nieuwe tools worden opgenomen. Cross-compilatie maakt het ook mogelijk om zowel 32-bits als 64-bits bibliotheken te bouwen op 64-bits geschikte hardware.
• Zorgvuldige manipulatie van de GCC-bron vertelt de compiler welke dynamische doellinker zal worden gebruikt.
Binutils wordt eerst geïnstalleerd omdat het configureer runs van zowel GCC als Glibc voeren verschillende functietests uit op de assembler en linker om te bepalen welke softwarefuncties moeten worden in- of uitgeschakeld. Dit is belangrijker dan men in eerste instantie zou beseffen. Een onjuist geconfigureerde GCC of Glibc kan resulteren in een subtiel kapotte toolchain, waarbij de impact van een dergelijke breuk mogelijk pas aan het einde van de bouw van een volledige distributie zichtbaar wordt. Een fout in de testsuite zal deze fout meestal benadrukken voordat er te veel extra werk wordt uitgevoerd.
Binutils installeert zijn assembler en linker op twee locaties, /gereedschap/bak en /tools/$LFS_TGT/bin. De tools op de ene locatie zijn nauw verbonden met de andere. Een belangrijk facet van de linker is de zoekvolgorde van de bibliotheek. Gedetailleerde informatie kunt u verkrijgen bij ld door het door te geven --uitgebreid vlag. Bijvoorbeeld, een ld --verbose | grep ZOEKEN illustreert de huidige zoekpaden en hun volgorde. Het laat zien welke bestanden zijn gekoppeld ld door een dummyprogramma te compileren en de --uitgebreid overschakelen naar de linker. Bijvoorbeeld, gcc dummy.c -Wl,--uitgebreid 2>&1
| grep geslaagd toont alle bestanden die met succes zijn geopend tijdens het koppelen.
Het volgende geïnstalleerde pakket is GCC. Een voorbeeld van wat er tijdens de uitvoering te zien is configureer is:
controleren welke assembler je moet gebruiken... /tools/i686-lfs-linux-gnu/bin/as controleren welke linker je moet gebruiken... /tools/i686-lfs-linux-gnu/bin/ld
controleren welke assembler je moet gebruiken... /tools/i686-lfs-linux-gnu/bin/as controleren welke linker je moet gebruiken... /tools/i686-lfs-linux-gnu/bin/ld
Dit is belangrijk om de hierboven genoemde redenen. Het laat ook zien dat het configuratiescript van GCC niet in de PATH-directory's zoekt om te vinden welke tools moeten worden gebruikt. Echter, tijdens de daadwerkelijke werking van gcc zelf worden niet noodzakelijkerwijs dezelfde zoekpaden gebruikt. Om erachter te komen welke standaard linker gcc zal gebruiken, uitvoeren: gcc -print-prog-naam=ld.
Gedetailleerde informatie kunt u verkrijgen bij gcc door het door te geven -v opdrachtregeloptie tijdens het compileren van een dummyprogramma. Bijvoorbeeld, gcc -v dummy.c toont gedetailleerde informatie over de preprocessor-, compilatie- en assemblagefasen, inclusief gcc's opgenomen zoekpaden en hun volgorde.
Vervolgens worden opgeschoonde Linux API-headers geïnstalleerd. Hierdoor kan de standaard C-bibliotheek (Glibc) communiceren met functies die de Linux-kernel zal bieden.
Het volgende geïnstalleerde pakket is Glibc. De belangrijkste overwegingen bij het bouwen van Glibc zijn de compiler, binaire tools en kernelheaders. De compiler is over het algemeen geen probleem, aangezien Glibc altijd de compiler zal gebruiken die betrekking heeft op het --gastheer parameter doorgegeven aan het configuratiescript; In ons geval zal dit bijvoorbeeld de compiler zijn i686-lfs-linux-gnu-gcc. De binaire tools en kernelheaders kunnen iets ingewikkelder zijn. Neem daarom geen risico en gebruik de beschikbare configuratieschakelaars om de juiste selecties af te dwingen. Na het rennen van configureer, controleer de inhoud van de config.make bestand in de glibc-build directory voor alle belangrijke details. Let op het gebruik van CC="i686-lfs-gnu-gcc" om te controleren welke binaire tools worden gebruikt en het gebruik van de -nostdinc en -isysteem vlaggen om het include-zoekpad van de compiler te beheren. Deze items benadrukken een belangrijk aspect van het Glibc-pakket: het is zeer zelfvoorzienend wat betreft de bouwmachines en is over het algemeen niet afhankelijk van standaardinstellingen voor de toolchain.
Tijdens de tweede passage van Binutils kunnen we de --met-lib-pad configureer de schakelaar om te bedienen ld's bibliotheekzoekpad.
Voor de tweede doorgang van GCC moeten de bronnen ervan ook worden aangepast om GCC te vertellen de nieuwe dynamische linker te gebruiken. Als u dit niet doet, zullen de GCC-programma's zelf de naam krijgen van de dynamische linker van het hostsysteem / lib directory die erin is ingebed, wat het doel om weg te komen van de host zou tenietdoen. Vanaf dit punt is de kerntoolchain op zichzelf staand en zelf-gehost. De rest van de Chapter 5-pakketten zijn allemaal gebouwd tegen de nieuwe Glibc /gereedschap.
Als je in hoofdstuk 6 de chroot-omgeving binnengaat, is Glibc het eerste grote pakket dat geïnstalleerd moet worden, vanwege het hierboven genoemde zelfvoorzienende karakter. Zodra deze Glibc is geïnstalleerd in / usr, zullen we een snelle omschakeling van de standaardinstellingen van de toolchain uitvoeren en vervolgens doorgaan met het bouwen van de rest van het doel-LFS-systeem.