Was ist Linux-Cross-Kompilierung?

Unter Linux bezieht sich Cross-Compilation auf das Generieren von ausführbarem Code auf einer Plattform auf einer anderen Plattform, dh die Plattform zum Kompilieren des Quellcodes und die Plattform zum Ausführen des kompilierten Programms des Quellcodes sind zwei verschiedene Plattformen. Gründe für die Verwendung der Cross-Compilation: 1. Das Zielsystem ist nicht in der Lage, nativ darauf zu kompilieren. 2. Die Plattform, die den Quellcode kompilieren kann, unterscheidet sich von der Zielplattform.

Die Betriebsumgebung dieses Tutorials: Linux5.9.8-System, Dell G3-Computer.

Cross-Kompilierung

Das sogenannte „Cross_Compile“ bedeutet, dass die Plattform zum Kompilieren des Quellcodes und die Plattform zum Ausführen des kompilierten Programms des Quellcodes zwei verschiedene Plattformen sind. Beispielsweise läuft unter der Plattform Intel x86-Architektur/Linux (Ubuntu) die mit der Cross-Compilation-Toolkette generierte ausführbare Datei unter der ARM-Architektur/Linux.

Einfach ausgedrückt geht es darum, ausführbaren Code auf einer Plattform auf einer anderen Plattform zu generieren. Auf derselben Architektur können verschiedene Betriebssysteme ausgeführt werden. Ebenso kann dasselbe Betriebssystem auch auf verschiedenen Architekturen ausgeführt werden.

Cross-Kompilierung ist relativ kompliziert und die folgenden Probleme müssen berücksichtigt werden:

• CPU-Architektur: wie ARM, x86, MIPS usw.;

• Byte-Reihenfolge: Big-Endian und Little-Endian;

• Unterstützung für Gleitkommazahlen;

• Application Binary Interface (ABI);

Warum Cross-Compilation verwenden? Es gibt zwei Hauptgründe:

• Das Zielsystem für die Kreuzkompilierung verfügt im Allgemeinen über wenig Speicher, schlechte oder gar keine Anzeigeausrüstung und kann nicht lokal darauf kompiliert werden.

• Eine Plattform, die dazu in der Lage ist Zum Kompilieren des Quellcodes unterscheidet sich die CPU-Architektur oder das Betriebssystem von der Zielplattform.

Die Cross-Compilation-Toolkette ist ein wesentliches Werkzeug für die Cross-Compilation und eine Fähigkeit, die eingebettete Entwickler kompetent beherrschen müssen.

Warum ist Cross-Compiling schwierig?

Portable native Kompilierung ist schwierig.

Die meisten Programme werden auf x86-Hardware entwickelt und nativ kompiliert. Beim Cross-Compilieren können zwei Arten von Problemen auftreten: Probleme mit dem Programm selbst und Probleme mit dem Build-System.

Die erste Kategorie von Problemen betrifft alle Nicht-x86-Ziele, einschließlich nativer und Cross-Builds. Die meisten Programme gehen von der Art der Maschine aus, auf der sie laufen. Diese muss mit der entsprechenden Plattform übereinstimmen, andernfalls läuft das Programm nicht. Zu den gängigen Annahmen gehören:

• Wortgröße – Das Kopieren von Zeigern auf int kann auf 64-Bit-Plattformen zu Datenverlusten führen. Die Bestimmung der Größe von malloc durch Multiplikation mit 4 anstelle von sizeof(long) ist schlecht. Ein Ganzzahlüberlauf führt zu einer geringfügigen Sicherheitslücke, z. B. „if (x+y

• Endianness – Verschiedene Systeme speichern Binärdaten intern auf unterschiedliche Weise, und das Lesen von Int- oder Float-Daten von der Festplatte oder dem Netzwerk erfordert möglicherweise eine Konvertierung.

• Ausrichtung – Einige Plattformen (z. B. Arm) können nur Ganzzahlen von Adressen lesen oder schreiben, die gerade Vielfache von 4 Bytes sind, andernfalls tritt ein Segfault auf. Die Verarbeitung aller ausgerichteten und nicht ausgerichteten Daten ist langsamer und der Compiler füllt normalerweise die Strukturausrichtungsvariablen aus. Strukturen als Datenblöcke zu behandeln, die an die Festplatte oder über das Netzwerk gesendet werden können, erfordert zusätzliche Arbeit, um eine konsistente Darstellung sicherzustellen.

• Standardsignatur – Der Datentyp „char“, der standardmäßig signiert oder unsigniert ist, variiert von Plattform zu Plattform (von Compiler zu Compiler), was zu einigen sehr überraschenden Fehlern führt. Die einfache Problemumgehung besteht darin, einen Compiler-Parameter wie „-funsigned-char“ bereitzustellen, um den Standardwert auf einen bekannten Wert zu erzwingen.

• NOMMU – Wenn die Zielplattform keine Speicherverwaltungseinheit hat, müssen einige Dinge geändert werden. Erfordert vfork(), nicht fork(), nur bestimmte Arten von mmap() funktionieren (gemeinsam genutzt oder schreibgeschützt, aber nicht Copy-on-Write), der Stapel wächst nicht dynamisch.

Die meisten Pakete sollen portierbar sein, wenn sie nativ kompiliert werden, und akzeptieren zumindest Patches, die eines der oben genannten Probleme beheben (außer NOMMU-Probleme), die an die entsprechende Entwicklungs-Mailingliste gesendet werden.

Dann Cross-Compilieren.

... „make install configure“-Abschnitt) testet normalerweise Dinge wie die Bytereihenfolge oder die Seitengröße und ist portierbar, wenn er nativ kompiliert wird. Beim Cross-Compilieren unterscheiden sich diese Werte zwischen Hostsystem und Zielsystem und die Ausführung des Tests auf dem Hostsystem führt zu falschen Antworten. Wenn das Ziel nicht über das Softwarepaket verfügt oder die Version nicht kompatibel ist, erkennt die Konfiguration, ob auf dem Host Softwarepaketunterstützung vorhanden ist.

HOSTCC vs. TARGETCC – Der Build-Prozess erfordert eine Kompilierung, um auf dem Host-System ausgeführt zu werden, wie die oben konfigurierten Tests, oder ein Programm, das Code generiert (wie ein C-Programm, das eine .h-Datei erstellt, #included während des Hauptbuilds) . Ersetzen Sie den Host-Compiler durch den Ziel-Compiler, wodurch die Laufzeitbibliothek während des Erstellungsprozesses beschädigt wird. Eine solche Bibliothek erfordert Zugriff auf die Host- und Zielcompiler und muss angegeben werden, wann sie verwendet werden soll.

Toolchain-Leckage – Eine falsch konfigurierte Cross-Compilation-Toolchain lässt einige Inhalte des Hostsystems in das kompilierte Programm gelangen, was zu Fehlern führt, die oft leicht zu erkennen, aber schwer zu diagnostizieren und zu beheben sind. Möglicherweise enthält die Toolchain die falschen Header-Dateien oder sucht beim Verknüpfen nach den falschen Bibliothekspfaden. Gemeinsam genutzte Bibliotheken sind oft von anderen gemeinsam genutzten Bibliotheken abhängig und schleichen sich möglicherweise unerwartete Linkzeitreferenzen in das Hostsystem ein.

Bibliotheken – Dynamisch verknüpfte Programme müssen zur Kompilierungszeit auf die entsprechenden gemeinsam genutzten Bibliotheken zugreifen. Die gemeinsam genutzte Bibliothek des Zielsystems muss zur Cross-Compilation-Toolkette hinzugefügt werden, damit das Programm darauf verlinken kann.

Testen – Bei nativen Builds bietet das Entwicklungssystem eine praktische Testumgebung. Beim Cross-Compilieren kann die Bestätigung, dass der „Hallo Welt“-Build erfolgreich war, die Konfiguration (mindestens) des Bootloaders, des Kernels, des Root-Dateisystems und der gemeinsam genutzten Bibliotheken erfordern.

• Fußnote 1: Der bedeutendste Unterschied zwischen Computertypen ist der Prozessor, der das Programm ausführt. Weitere Unterschiede umfassen Bibliotheks-ABI (z. B. glibc vs. uClibc), Maschinen mit konfigurierbarer Endianness (Arm mit Armeb), oder ein anderer Maschinenmodus, der 32-Bit- und 64-Bit-Code ausführen kann (z. B. x86-64 auf x86).

• Fußnote 2: Beim Erstellen eines Compilers wird der dritte Typ als „Canadian Cross“ bezeichnet, ein Cross-Compiler, der nicht auf dem Hostsystem läuft. Canadian Cross-Build ist ein Compiler, der auf einer Zielplattform läuft und Code auf einem anderen Zielrechner generiert. Erstellen Sie zunächst einen temporären Cross-Compiler vom Host zum ersten Ziel und erstellen Sie als zweites Ziel einen weiteren Cross-Compiler, um einen solchen externen Compiler zu erstellen. Das Ziel des ersten Cross-Compilers wird zum Hostcomputer, auf dem der neue Compiler ausgeführt wird, und das zweite Ziel ist die Plattform, auf der der neue Compiler Ausgaben generiert. Diese Technik wird häufig zum Cross-Kompilieren eines neuen nativen Compilers für die Zielplattform verwendet.

• Fußnote 3: Moderne Desktop-Systeme sind schnell genug, dass die Emulation von nativ unter dem Emulator kompilierten Zielen tatsächlich eine praktikable Strategie ist. Viel langsamer als Cross-Compiling, erfordert das Finden oder Generieren einer nativen Build-Umgebung für das Ziel (ein Cross-Compiler muss ohnehin eingerichtet werden) und kann aufgrund von Unterschieden zwischen dem Emulator und der tatsächlich einzusetzenden Hardware abstürzen.

• Fußnote 4: Cross-Compilation-Toolchains neigen dazu, den Namen ihrer Dienstprogramme voranzustellen, ala „armv5l-linux-gcc“. Wenn es einfach „gcc“ heißt, können sich der Host- und der native Compiler nicht gleichzeitig in $PATH befinden.

Verwandte Empfehlungen: „Linux-Video-Tutorial“

Das obige ist der detaillierte Inhalt vonWas ist Linux-Cross-Kompilierung?. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!