Dokumentation5.2. Technische Hinweise zur Toolchain
In diesem Abschnitt werden einige der Gründe und technischen Details der gesamten Build-Methode erläutert. Es ist nicht unbedingt erforderlich, alles in diesem Abschnitt sofort zu verstehen. Die meisten dieser Informationen werden nach der Durchführung eines tatsächlichen Builds klarer. Auf diesen Abschnitt kann während des Prozesses jederzeit zurückgegriffen werden.
Das übergeordnete Ziel von Kapitel 5 besteht darin, einen temporären Bereich zu erstellen, der einen nachweislich funktionierenden Satz von Tools enthält, der vom Hostsystem isoliert werden kann. Durch die Nutzung Chroot, werden die Befehle in den verbleibenden Kapiteln in dieser Umgebung enthalten sein und so einen sauberen, störungsfreien Aufbau des Ziel-LFS-Systems gewährleisten. Der Erstellungsprozess wurde entwickelt, um die Risiken für neue Leser zu minimieren und gleichzeitig den größtmöglichen Bildungswert zu bieten.
Note
Bevor Sie fortfahren, machen Sie sich mit dem Namen der Arbeitsplattform vertraut, die oft als Ziel-Triplett bezeichnet wird. Eine einfache Möglichkeit, den Namen des Zieltripletts zu ermitteln, besteht darin, Folgendes auszuführen config.guess Skript, das mit der Quelle für viele Pakete geliefert wird. Entpacken Sie die Binutils-Quellen und führen Sie das Skript aus: ./config.guess und notieren Sie sich die Ausgabe. Für einen 32-Bit-Intel-Prozessor lautet die Ausgabe beispielsweise i686-pc-linux-gnu. Auf einem 64-Bit-System wird es so sein x86_64-pc-linux-gnu.
Beachten Sie auch den Namen des dynamischen Linkers der Plattform, der oft als dynamischer Loader bezeichnet wird (nicht zu verwechseln mit dem Standard-Linker). ld das ist Teil von Binutils). Der von Glibc bereitgestellte dynamische Linker findet und lädt die von einem Programm benötigten gemeinsam genutzten Bibliotheken, bereitet das Programm für die Ausführung vor und führt es dann aus. Der Name des dynamischen Linkers für einen 32-Bit-Intel-Computer lautet ld-linux.so.2 (ld-linux-x86-64.so.2 für 64-Bit-Systeme). Eine sichere Möglichkeit, den Namen des dynamischen Linkers zu ermitteln, besteht darin, eine zufällige Binärdatei vom Hostsystem zu überprüfen, indem Sie Folgendes ausführen: readelf -l | grep-Interpreter und die Ausgabe notieren. Die maßgebliche Referenz für alle Plattformen finden Sie im Shlib-Versionen Datei im Stammverzeichnis des Glibc-Quellbaums.
Note
Bevor Sie fortfahren, machen Sie sich mit dem Namen der Arbeitsplattform vertraut, die oft als Ziel-Triplett bezeichnet wird. Eine einfache Möglichkeit, den Namen des Zieltripletts zu ermitteln, besteht darin, Folgendes auszuführen config.guess Skript, das mit der Quelle für viele Pakete geliefert wird. Entpacken Sie die Binutils-Quellen und führen Sie das Skript aus: ./config.guess und notieren Sie sich die Ausgabe. Für einen 32-Bit-Intel-Prozessor lautet die Ausgabe beispielsweise i686-pc-linux-gnu. Auf einem 64-Bit-System wird es so sein x86_64-pc-linux-gnu.
Beachten Sie auch den Namen des dynamischen Linkers der Plattform, der oft als dynamischer Loader bezeichnet wird (nicht zu verwechseln mit dem Standard-Linker). ld das ist Teil von Binutils). Der von Glibc bereitgestellte dynamische Linker findet und lädt die von einem Programm benötigten gemeinsam genutzten Bibliotheken, bereitet das Programm für die Ausführung vor und führt es dann aus. Der Name des dynamischen Linkers für einen 32-Bit-Intel-Computer lautet ld-linux.so.2 (ld-linux-x86-64.so.2 für 64-Bit-Systeme). Eine sichere Möglichkeit, den Namen des dynamischen Linkers zu ermitteln, besteht darin, eine zufällige Binärdatei vom Hostsystem zu überprüfen, indem Sie Folgendes ausführen: readelf -l | grep-Interpreter und die Ausgabe notieren. Die maßgebliche Referenz für alle Plattformen finden Sie im Shlib-Versionen Datei im Stammverzeichnis des Glibc-Quellbaums.
Einige wichtige technische Punkte zur Funktionsweise der Build-Methode in Kapitel 5:
• Leichte Anpassung des Namens der Arbeitsplattform, indem das Ziel-Triplett „Anbieter“ über das Feld „Anbieter“ geändert wird LFS_TGT Variable stellt sicher, dass der erste Build von Binutils und GCC einen kompatiblen Cross-Linker und Cross-Compiler erzeugt. Anstatt Binärdateien für eine andere Architektur zu erstellen, erzeugen der Cross-Linker und Cross-Compiler Binärdateien, die mit der aktuellen Hardware kompatibel sind.
• Die temporären Bibliotheken werden übergreifend kompiliert. Da sich ein Cross-Compiler naturgemäß nicht auf irgendetwas von seinem Hostsystem verlassen kann, beseitigt diese Methode eine potenzielle Kontamination des Zielsystems, indem sie die Wahrscheinlichkeit verringert, dass Header oder Bibliotheken vom Host in die neuen Tools integriert werden. Durch die Kreuzkompilierung besteht außerdem die Möglichkeit, sowohl 32-Bit- als auch 64-Bit-Bibliotheken auf 64-Bit-fähiger Hardware zu erstellen.
• Eine sorgfältige Manipulation der GCC-Quelle teilt dem Compiler mit, welcher dynamische Ziellinker verwendet wird.
Binutils wird zuerst installiert, da die konfigurieren Läufe von GCC und Glibc führen verschiedene Funktionstests auf dem Assembler und Linker durch, um zu bestimmen, welche Softwarefunktionen aktiviert oder deaktiviert werden müssen. Das ist wichtiger, als man zunächst vermuten könnte. Eine falsch konfigurierte GCC oder Glibc kann zu einer subtilen Unterbrechung der Toolchain führen, wobei die Auswirkungen einer solchen Unterbrechung möglicherweise erst gegen Ende der Erstellung einer gesamten Distribution sichtbar werden. Ein Testsuite-Fehler macht diesen Fehler normalerweise deutlich, bevor zu viel zusätzliche Arbeit geleistet wird.
Binutils installiert seinen Assembler und Linker an zwei Orten: /tools/bin und /tools/$LFS_TGT/bin. Die Werkzeuge an einem Ort sind fest mit dem anderen verbunden. Ein wichtiger Aspekt des Linkers ist seine Bibliothekssuchreihenfolge. Detaillierte Informationen erhalten Sie unter ld indem man es weitergibt - ausführlich Flagge. Zum Beispiel ein ld --verbose | grep SUCHE veranschaulicht die aktuellen Suchpfade und deren Reihenfolge. Es zeigt an, welche Dateien verlinkt sind ld durch Kompilieren eines Dummy-Programms und Übergeben des - ausführlich Wechseln Sie zum Linker. Zum Beispiel, gcc dummy.c -Wl,--verbose 2>&1
| grep success zeigt alle Dateien an, die während der Verknüpfung erfolgreich geöffnet wurden.
Das nächste installierte Paket ist GCC. Ein Beispiel dafür, was während seines Laufs zu sehen ist konfigurieren ist:
Überprüfen, welcher Assembler verwendet werden soll... /tools/i686-lfs-linux-gnu/bin/as Überprüfen, welcher Linker verwendet werden soll... /tools/i686-lfs-linux-gnu/bin/ld
Überprüfen, welcher Assembler verwendet werden soll... /tools/i686-lfs-linux-gnu/bin/as Überprüfen, welcher Linker verwendet werden soll... /tools/i686-lfs-linux-gnu/bin/ld
Dies ist aus den oben genannten Gründen wichtig. Es zeigt auch, dass das Konfigurationsskript von GCC nicht die PATH-Verzeichnisse durchsucht, um herauszufinden, welche Tools verwendet werden sollen. Während des eigentlichen Betriebs von gcc selbst werden nicht unbedingt die gleichen Suchpfade verwendet. Um herauszufinden, welcher Standard-Linker gcc wird verwenden, ausführen: gcc -print-prog-name=ld.
Detaillierte Informationen erhalten Sie unter gcc indem man es weitergibt -v Befehlszeilenoption beim Kompilieren eines Dummy-Programms. Zum Beispiel, gcc -v dummy.c zeigt detaillierte Informationen über die Präprozessor-, Kompilierungs- und Montagephasen an, einschließlich gccenthält Suchpfade und deren Reihenfolge.
Als nächstes werden bereinigte Linux-API-Header installiert. Diese ermöglichen der Standard-C-Bibliothek (Glibc) die Verbindung mit Funktionen, die der Linux-Kernel bereitstellt.
Das nächste installierte Paket ist Glibc. Die wichtigsten Überlegungen zum Erstellen von Glibc sind der Compiler, die Binärtools und die Kernel-Header. Der Compiler stellt im Allgemeinen kein Problem dar, da Glibc immer den entsprechenden Compiler verwendet --Gastgeber Parameter, der an sein Konfigurationsskript übergeben wird; In unserem Fall ist es beispielsweise der Compiler i686-lfs-linux-gnu-gcc. Die Binärtools und Kernel-Header können etwas komplizierter sein. Gehen Sie daher kein Risiko ein und nutzen Sie die verfügbaren Konfigurationsschalter, um die richtige Auswahl zu erzwingen. Nach dem Lauf von konfigurieren, überprüfen Sie den Inhalt der config.make Datei in das glibc-build Verzeichnis für alle wichtigen Details. Beachten Sie die Verwendung von CC="i686-lfs-gnu-gcc" um zu steuern, welche binären Tools verwendet werden und wie sie verwendet werden -nostdinc und -isystem Flags zur Steuerung des Include-Suchpfads des Compilers. Diese Elemente heben einen wichtigen Aspekt des Glibc-Pakets hervor: Es ist hinsichtlich seiner Build-Maschinerie sehr autark und verlässt sich im Allgemeinen nicht auf Toolchain-Standardeinstellungen.
Während des zweiten Durchgangs von Binutils können wir das nutzen --with-lib-path Schalter zur Steuerung konfigurieren ldSuchpfad der Bibliothek.
Für den zweiten Durchgang von GCC müssen auch dessen Quellen geändert werden, um GCC anzuweisen, den neuen dynamischen Linker zu verwenden. Andernfalls führt dies dazu, dass die GCC-Programme selbst den Namen des dynamischen Linkers vom Hostsystem erhalten / lib in sie eingebettetes Verzeichnis, was das Ziel, dem Host zu entkommen, zunichte machen würde. Ab diesem Zeitpunkt ist die Kern-Toolchain eigenständig und selbstgehostet. Der Rest der Kapitel 5-Pakete baut alle auf der neuen Glibc auf /Werkzeuge.
Beim Betreten der Chroot-Umgebung in Kapitel 6 wird Glibc aufgrund seiner oben erwähnten autarken Natur als erstes großes Paket installiert. Sobald diese Glibc installiert ist / usr, führen wir eine schnelle Umstellung der Toolchain-Standardeinstellungen durch und fahren dann mit dem Aufbau des restlichen LFS-Zielsystems fort.