Cross-Compiler - Cross compiler

Programmausführung
Allgemeine Konzepte
Codearten
Kompilierungsstrategien
Bemerkenswerte Laufzeiten
Bemerkenswerte Compiler und Toolchains

Ein Cross-Compiler ist ein Compiler , der in der Lage ist, ausführbaren Code für eine andere Plattform als diejenige zu erstellen, auf der der Compiler ausgeführt wird. Ein Compiler, der beispielsweise auf einem PC ausgeführt wird, aber Code generiert, der auf einem Android- Smartphone ausgeführt wird, ist ein Cross-Compiler.

Ein Cross-Compiler ist erforderlich, um Code für mehrere Plattformen von einem Entwicklungshost aus zu kompilieren. Eine direkte Kompilierung auf der Zielplattform ist möglicherweise nicht möglich, beispielsweise auf eingebetteten Systemen mit begrenzten Rechenressourcen.

Cross-Compiler unterscheiden sich von Source-to-Source-Compilern . Ein Cross-Compiler dient der plattformübergreifenden Software- Generierung von Maschinencode, während ein Source-to-Source-Compiler in Textcode von einer Programmiersprache in eine andere übersetzt. Beides sind Programmierwerkzeuge .

Verwenden

Die grundlegende Verwendung eines Cross-Compilers besteht darin, die Build-Umgebung von der Zielumgebung zu trennen. Dies ist in mehreren Situationen nützlich:

  • Eingebettete Computer, bei denen ein Gerät über extrem begrenzte Ressourcen verfügt. Beispielsweise verfügt ein Mikrowellenherd über einen extrem kleinen Computer, um seine Tastatur und seinen Türsensor abzulesen, eine Ausgabe an eine digitale Anzeige und einen Lautsprecher zu liefern und die Maschinerie zum Kochen von Speisen zu steuern. Dieser Computer ist im Allgemeinen nicht leistungsfähig genug, um einen Compiler, ein Dateisystem oder eine Entwicklungsumgebung auszuführen.
  • Kompilieren für mehrere Maschinen. Beispielsweise möchte ein Unternehmen möglicherweise mehrere verschiedene Versionen eines Betriebssystems oder mehrere verschiedene Betriebssysteme unterstützen. Durch die Verwendung eines Cross-Compilers kann eine einzelne Build-Umgebung eingerichtet werden, um für jedes dieser Ziele zu kompilieren.
  • Kompilieren auf einer Serverfarm . Ähnlich wie beim Kompilieren für mehrere Computer kann ein komplizierter Build, der viele Kompilierungsvorgänge umfasst, auf jedem freien Computer ausgeführt werden, unabhängig von der zugrunde liegenden Hardware oder der Betriebssystemversion, auf der er ausgeführt wird.
  • Bootstrapping zu einer neuen Plattform. Bei der Entwicklung von Software für eine neue Plattform oder den Emulator einer zukünftigen Plattform verwendet man einen Cross-Compiler, um notwendige Tools wie das Betriebssystem und einen nativen Compiler zu kompilieren.
  • Kompilieren von nativem Code für Emulatoren für ältere, mittlerweile veraltete Plattformen wie den Commodore 64 oder Apple II von Enthusiasten, die Cross-Compiler verwenden, die auf einer aktuellen Plattform laufen (wie die MS-DOS 6502- Cross-Compiler von Aztec C, die unter Windows XP laufen ).

Die Verwendung von virtuellen Maschinen (wie Javas JVM ) löst einige der Gründe, aus denen Cross-Compiler entwickelt wurden. Das Paradigma der virtuellen Maschine ermöglicht die Verwendung derselben Compilerausgabe auf mehreren Zielsystemen, obwohl dies nicht immer ideal ist, da virtuelle Maschinen oft langsamer sind und das kompilierte Programm nur auf Computern mit dieser virtuellen Maschine ausgeführt werden kann.

Typischerweise unterscheidet sich die Hardwarearchitektur (zB Kompilieren eines Programms, das für die MIPS-Architektur auf einem x86- Computer bestimmt ist), aber Kreuzkompilierung ist auch anwendbar, wenn nur die Betriebssystemumgebung unterschiedlich ist, wie beim Kompilieren eines FreeBSD- Programms unter Linux oder sogar nur der Systembibliothek , wie beim Kompilieren von Programmen mit uClibc auf einem glibc- Host.

Kanadisches Kreuz

Das Canadian Cross ist eine Technik zum Erstellen von Cross-Compilern für andere Maschinen. Bei drei Maschinen A, B und C verwendet man Maschine A (zB mit Windows XP auf einem IA-32- Prozessor), um einen Cross-Compiler zu bauen, der auf Maschine B (zB mit Mac OS X auf einem x86-64- Prozessor) läuft, um ausführbare Dateien für Maschine C erstellen (zB mit Android auf einem ARM- Prozessor). Bei der Verwendung des Canadian Cross mit GCC können vier Compiler beteiligt sein

  • Der proprietäre native Compiler für Maschine A (1) (zB Compiler von Microsoft Visual Studio ) wird verwendet, um den gcc native Compiler für Maschine A (2) zu bauen .
  • Der native gcc-Compiler für Maschine A (2) wird verwendet, um den gcc-Cross-Compiler von Maschine A zu Maschine B zu erstellen (3)
  • Der gcc-Cross-Compiler von Maschine A zu Maschine B (3) wird verwendet, um den gcc-Cross-Compiler von Maschine B zu Maschine C zu bauen (4)

Beispiel für Canadian Cross, Schema

Der Endergebnis-Cross-Compiler (4) kann auf Build-Maschine A nicht ausgeführt werden; Stattdessen würde es auf Computer B ausgeführt, um eine Anwendung in ausführbaren Code zu kompilieren, der dann auf Computer C kopiert und auf Computer C ausgeführt würde.

Zum Beispiel NetBSD stellt einen POSIX - Unix - Shell - Skript namens , build.shdie seinen eigenen ersten bauen Toolchain mit der Host-Compiler; Dies wiederum wird verwendet, um den Cross-Compiler zu erstellen, der zum Erstellen des gesamten Systems verwendet wird.

Der Begriff Canadian Cross entstand, weil Kanada zu der Zeit, als diese Themen diskutiert wurden, drei nationale politische Parteien hatte.

Zeitleiste der frühen Cross-Compiler

  • 1979 – ALGOL 68C generiert ZCODE ; Dies half bei der Portierung des Compilers und anderer ALGOL 68-Anwendungen auf alternative Plattformen. Um den ALGOL 68C Compiler zu kompilieren benötigte man ca. 120 KB Speicher. Bei Z80 sind seine 64 KB Speicher zu klein, um den Compiler tatsächlich zu kompilieren. Für den Z80 musste der Compiler selbst also von dem größeren CAP-Fähigkeitscomputer oder einem IBM System/370- Mainframe querkompiliert werden.

GCC und Cross-Compilation

GCC , eine kostenlose Softwaresammlung von Compilern, kann für Cross-Compilierung eingerichtet werden. Es unterstützt viele Plattformen und Sprachen.

GCC erfordert, dass für jede Zielplattform eine kompilierte Kopie von Binutils verfügbar ist. Besonders wichtig ist der GNU-Assembler . Daher muss binutils zuerst mit dem --target=some-targetan das configure-Skript gesendeten Schalter korrekt kompiliert werden . GCC muss auch mit der gleichen Option konfiguriert werden--target . GCC kann dann normal ausgeführt werden, vorausgesetzt, dass die Tools, die binutils erstellt, im Pfad verfügbar sind , was wie folgt erfolgen kann (auf UNIX-ähnlichen Betriebssystemen mit bash): 

PATH=/path/to/binutils/bin:${PATH} make

Cross-Kompilierung GCC setzt voraus , dass ein Teil der Zielplattform‘ s C - Standardbibliothek auf der zur Verfügung Host - Plattform . Der Programmierer kann sich dafür entscheiden, die vollständige C-Bibliothek zu kompilieren, aber diese Wahl könnte unzuverlässig sein. Die Alternative besteht darin, newlib zu verwenden , eine kleine C-Bibliothek, die nur die wichtigsten Komponenten enthält, die zum Kompilieren von C- Quellcode erforderlich sind .

Die GNU-Autotools- Pakete (dh autoconf , automake und libtool ) verwenden den Begriff einer Build-Plattform , einer Host-Plattform und einer Zielplattform . Auf der Build-Plattform wird der Compiler tatsächlich kompiliert. In den meisten Fällen sollte build undefiniert bleiben (es wird standardmäßig vom Host verwendet). Auf der Host-Plattform werden immer die Ausgabeartefakte des Compilers ausgeführt, unabhängig davon, ob es sich bei der Ausgabe um einen anderen Compiler handelt oder nicht. Die Zielplattform wird beim Cross-Kompilieren von Cross-Compilern verwendet. Sie stellt dar, welche Art von Objektcode das Paket selbst erzeugt; andernfalls ist die Einstellung der Zielplattform irrelevant. Ziehen Sie beispielsweise in Betracht, ein Videospiel zu kompilieren, das auf einem Dreamcast ausgeführt wird . Die Maschine, auf der das Spiel kompiliert wird, ist die Build-Plattform, während Dreamcast die Host-Plattform ist . Die Namen host und target sind relativ zum verwendeten Compiler und wie son und grandson verschoben .

Eine andere Methode allgemein von Embedded - Linux - Entwickler verwendet , beinhaltet die Kombination von GCC Compiler mit spezialisierten Sandkästen wie Scratchbox , scratchbox2 oder Proot . Diese Tools erstellen eine " chrooted " Sandbox, in der der Programmierer die notwendigen Tools, libc und Bibliotheken aufbauen kann, ohne zusätzliche Pfade setzen zu müssen. Es werden auch Einrichtungen bereitgestellt, um die Laufzeit zu "täuschen", so dass sie "glaubt", dass sie tatsächlich auf der beabsichtigten Ziel-CPU (wie einer ARM-Architektur) läuft; Dadurch können Konfigurationsskripte und dergleichen fehlerfrei ausgeführt werden. Scratchbox läuft im Vergleich zu Methoden ohne Chroot langsamer, und die meisten Tools, die sich auf dem Host befinden, müssen in Scratchbox verschoben werden, um zu funktionieren.

Manx Aztec C Cross-Compiler

Manx Software Systems aus Shrewsbury , New Jersey , produzierte ab den 1980er Jahren C-Compiler für professionelle Entwickler für eine Vielzahl von Plattformen bis hin zu PCs und Macs .

Die Programmiersprache Aztec C von Manx war für eine Vielzahl von Plattformen verfügbar, darunter MS-DOS , Apple II , DOS 3.3 und ProDOS , Commodore 64 , Macintosh 68XXX und Amiga .

Von den 1980er Jahren und in den 1990er Jahren bis zum Verschwinden von Manx Software Systems wurde die MS-DOS-Version von Aztec C sowohl als Compiler im nativen Modus als auch als Cross-Compiler für andere Plattformen mit verschiedenen Prozessoren einschließlich Commodore 64 und Apple II angeboten. Für Aztec C gibt es noch Internet-Distributionen einschließlich ihrer MS-DOS-basierten Cross-Compiler. Sie sind heute noch im Einsatz.

Der Aztec C86 von Manx, ihr 8086- MS-DOS-Compiler im nativen Modus , war ebenfalls ein Cross-Compiler. Obwohl es keinen Code für einen anderen Prozessor wie ihre Aztec C65 6502 Cross-Compiler für Commodore 64 und Apple II kompilierte, erstellte es binäre ausführbare Dateien für damalige ältere Betriebssysteme für die 16-Bit-8086-Prozessorfamilie.

Als der IBM PC zum ersten Mal eingeführt wurde, war er mit einer Auswahl an Betriebssystemen erhältlich, darunter CP/M-86 und PC DOS . Aztec C86 wurde mit Linkbibliotheken zum Generieren von Code für beide IBM PC- Betriebssysteme bereitgestellt . In den 1980er Jahren fügten spätere Versionen von Aztec C86 (3.xx, 4.xx und 5.xx) Unterstützung für MS-DOS "vorübergehende" Versionen 1 und 2 hinzu, die weniger robust waren als die "Basis" MS-DOS Version 3 und später, auf das Aztec C86 bis zu seinem Untergang zielte.

Schließlich bot Aztec C86 Entwicklern der C-Sprache die Möglichkeit, ROM-fähigen "HEX" -Code zu erstellen, der dann mit einem ROM-Brenner direkt auf einen 8086-basierten Prozessor übertragen werden konnte. Para kann häufiger heute sein , aber die Praxis Low-Level - ROM - Code zu schaffen , war häufiger pro Kopf in diesen Jahren , wenn Gerätetreiber Entwicklung oft von Anwendungsprogrammierern für einzelne Anwendungen durchgeführt wurde, und neue Geräte beliefen sich auf eine Heimindustrie . Es war nicht ungewöhnlich, dass Anwendungsprogrammierer ohne Unterstützung des Herstellers direkt mit der Hardware verbunden waren. Diese Praxis war der heutigen Entwicklung von Embedded Systems ähnlich .

Thomas Fenwick und James Goodnow II waren die beiden Hauptentwickler von Aztec-C. Fenwick wurde später als Autor des Microsoft Windows CE- Kernels oder NK ("New Kernel"), wie es damals genannt wurde, bekannt.

Microsoft C Cross-Compiler

Frühgeschichte – 1980er Jahre

Microsoft C (MSC) hat eine kürzere Geschichte als andere, die bis in die 1980er Jahre zurückreicht. Die ersten Microsoft C-Compiler wurden von derselben Firma hergestellt, die Lattice C hergestellt hatte, und wurden von Microsoft in ihre eigenen umbenannt, bis MSC 4 veröffentlicht wurde, die erste Version, die Microsoft selbst produzierte.

1987 begannen viele Entwickler, auf Microsoft C umzusteigen, und viele weitere folgten während der Entwicklung von Microsoft Windows bis zu seinem heutigen Zustand. Es entstanden Produkte wie Clipper und später Clarion , die eine einfache Entwicklung von Datenbankanwendungen durch den Einsatz sprachenübergreifender Techniken ermöglichten, wodurch ein Teil ihrer Programme mit Microsoft C kompiliert werden konnte.

Borland C (kalifornisches Unternehmen) war Jahre vor der Veröffentlichung seines ersten C-Produkts durch Microsoft erhältlich.

Lange vor Borland hatte BSD Unix (Berkeley University) C von den Autoren der C-Sprache bekommen: Kernighan und Ritchie , die es gemeinsam geschrieben haben, während sie für AT&T (Labs) arbeiteten. Die ursprünglichen Bedürfnisse von K&R waren nicht nur die elegante parsierte Syntax der zweiten Ebene, um die geparste Syntax der ersten Ebene zu ersetzen am wenigsten Supportcode pro Plattform, den sie brauchten.). Auch das gestrige C steht in direktem Zusammenhang mit ASM-Code, wo immer nicht plattformabhängig. Heutiges C (eher C++) ist nicht mehr C-kompatibel und der zugrunde liegende ASM-Code kann sich stark von dem auf einer bestimmten Plattform geschriebenen unterscheiden (in Linux: manchmal ersetzt er Bibliotheksaufrufe und leitet sie durch Verteilerauswahlen um). Das heutige C ist eine Sprache der 3. oder 4. Stufe, die auf die alte Weise wie eine Sprache der 2. Stufe verwendet wird.

1987

C-Programme waren seit langem mit in Assembler geschriebenen Modulen verknüpft . Die meisten C-Compiler (sogar aktuelle Compiler) bieten einen Assembler-Pass (der aus Effizienzgründen optimiert und dann nach dem Assemblieren mit dem Rest des Programms verknüpft werden kann).

Compiler wie Aztec-C konvertierten alles in einem separaten Durchgang in Assemblersprache und stellten dann den Code in einem separaten Durchgang zusammen und waren für ihren sehr effizienten und kleinen Code bekannt, aber 1987 war der in Microsoft C integrierte Optimierer sehr gut und nur "geschäftskritische" Teile eines Programms wurden normalerweise für das Umschreiben in Betracht gezogen. Tatsächlich hatte sich die C-Sprachprogrammierung als Sprache der "niedrigsten Ebene" durchgesetzt, wobei die Programmierung zu einer multidisziplinären Wachstumsbranche wurde und die Projekte größer wurden, wobei Programmierer Benutzeroberflächen und Datenbankschnittstellen in höheren Sprachen schrieben, und ein Bedarf bestand entstand für die sprachübergreifende Entwicklung, die bis heute andauert.

1987, mit der Veröffentlichung von MSC 5.1, bot Microsoft eine sprachübergreifende Entwicklungsumgebung für MS-DOS an. 16-Bit-Binärobjektcode, der in Assemblersprache ( MASM ) und anderen Microsoft-Sprachen wie QuickBASIC , Pascal und Fortran geschrieben wurde, konnte in einem Prozess, den sie "Mixed Language Programming" und jetzt "InterLanguage Calling" nannten, zu einem Programm verknüpft werden. Wenn BASIC in dieser Mischung verwendet wurde, musste das Hauptprogramm in BASIC sein, um das interne Laufzeitsystem zu unterstützen , das BASIC für die Garbage Collection und seine anderen verwalteten Operationen kompilierte, die einen BASIC- Interpreter wie QBasic in MS-DOS simulierten .

Die Aufrufkonvention für C-Code bestand insbesondere darin, Parameter in "umgekehrter Reihenfolge" auf dem Stack und Rückgabewerte auf dem Stack statt in einem Prozessorregister zu übergeben . Es gab andere Programmierregeln, damit alle Sprachen zusammenarbeiten, aber diese spezielle Regel blieb durch die sprachübergreifende Entwicklung bestehen, die sich durch die Windows 16- und 32-Bit-Versionen hindurch und in der Entwicklung von Programmen für OS/2 fortsetzte und die bis heute andauert Tag. Sie ist als Pascal-Aufrufkonvention bekannt .

Eine andere Art der Kreuzkompilierung , für die Microsoft C während dieser Zeit verwendet wurde, war in Einzelhandelsanwendungen, die Handheld-Geräte wie das PDT3100 von Symbol Technologies (zur Inventarisierung ) erfordern , das eine Linkbibliothek für einen 8088- basierten Barcodeleser bereitstellte . Die Anwendung wurde auf dem Host-Computer erstellt und dann (über ein serielles Kabel ) auf das Handheld-Gerät übertragen, wo sie ausgeführt wurde, ähnlich wie es heute für denselben Markt mit Windows Mobile von Unternehmen wie Motorola , die Symbol gekauft haben , getan wird .

Anfang der 1990er Jahre

In den 1990er Jahren und beginnend mit MSC 6 (ihrem ersten ANSI C- kompatiblen Compiler) konzentrierte Microsoft seine C-Compiler wieder auf den aufstrebenden Windows-Markt und auch auf OS/2 und die Entwicklung von GUI- Programmen. Die Kompatibilität mit gemischten Sprachen blieb durch MSC 6 auf der MS-DOS-Seite erhalten, aber die API für Microsoft Windows 3.0 und 3.1 wurde in MSC 6 geschrieben. MSC 6 wurde auch erweitert, um Unterstützung für 32-Bit-Assemblys und Unterstützung für das aufkommende Windows for Workgroups bereitzustellen und Windows NT, die die Grundlage für Windows XP bilden würden . Eine Programmierpraxis namens Thunk wurde eingeführt, um die Übergabe zwischen 16- und 32-Bit-Programmen zu ermöglichen, die die Laufzeitbindung ( dynamische Verknüpfung ) anstelle der statischen Bindung nutzten , die in monolithischen 16-Bit-MS-DOS-Anwendungen bevorzugt wurde . Statische Bindung wird von einigen nativen Codeentwicklern immer noch bevorzugt, bietet jedoch im Allgemeinen nicht den Grad an Codewiederverwendung , der von neueren Best Practices wie dem Capability Maturity Model (CMM) gefordert wird .

MS-DOS-Unterstützung wurde noch mit der Veröffentlichung von Microsofts erstem C++-Compiler, MSC 7, bereitgestellt, der mit der Programmiersprache C und MS-DOS abwärtskompatibel war und sowohl die 16- als auch die 32-Bit-Codegenerierung unterstützte.

MSC übernahm dort, wo Aztec C86 aufgehört hatte. Der Marktanteil der C-Compiler hatte sich zu Cross-Compilern entwickelt, die die neuesten und besten Windows-Funktionen nutzten, C und C++ in einem einzigen Bundle anboten und immer noch MS-DOS-Systeme unterstützten, die bereits ein Jahrzehnt alt waren, und die kleineren Unternehmen, die produzierte Compiler wie Aztec C konnten nicht mehr konkurrieren und wandten sich entweder Nischenmärkten wie eingebetteten Systemen zu oder verschwanden.

Die Unterstützung der MS-DOS- und 16-Bit-Codegenerierung wurde bis MSC 8.00c fortgesetzt, das mit Microsoft C++ und Microsoft Application Studio 1.5 gebündelt wurde, dem Vorläufer von Microsoft Visual Studio , der heute von Microsoft bereitgestellten übergreifenden Entwicklungsumgebung.

Ende der 1990er Jahre

MSC 12 wurde mit Microsoft Visual Studio 6 veröffentlicht und bot keine Unterstützung mehr für MS-DOS-16-Bit-Binärdateien, sondern unterstützte stattdessen 32-Bit-Konsolenanwendungen, bot jedoch Unterstützung für die Codegenerierung unter Windows 95 und Windows 98 sowie für Windows NT . Linkbibliotheken waren für andere Prozessoren verfügbar, auf denen Microsoft Windows ausgeführt wurde; eine Praxis, die Microsoft bis heute fortsetzt.

MSC 13 wurde mit Visual Studio 2003 veröffentlicht und MSC 14 wurde mit Visual Studio 2005 veröffentlicht , die beide noch Code für ältere Systeme wie Windows 95 produzieren, aber Code für mehrere Zielplattformen einschließlich des mobilen Markts und der ARM-Architektur produzieren .

.NET und darüber hinaus

2001 entwickelte Microsoft die Common Language Runtime (CLR), die den Kern ihres .NET Framework- Compilers in der Visual Studio IDE bildete. Diese Schicht auf dem Betriebssystem, die sich in der API befindet, ermöglicht das Mischen von Entwicklungssprachen, die auf Plattformen kompiliert wurden, auf denen das Windows-Betriebssystem ausgeführt wird.

Die .NET Framework-Laufzeit und CLR bieten eine Zuordnungsebene für die Kernroutinen für den Prozessor und die Geräte auf dem Zielcomputer. Der C-Befehlszeilen-Compiler in Visual Studio kompiliert nativen Code für eine Vielzahl von Prozessoren und kann verwendet werden, um die Kernroutinen selbst zu erstellen.

Microsoft .NET-Anwendungen für Zielplattformen wie Windows Mobile auf der ARM-Architektur kompilieren auf Windows-Rechnern mit einer Vielzahl von Prozessoren und Microsoft bietet auch Emulatoren und Remote-Deployment-Umgebungen, die sehr wenig Konfiguration erfordern, im Gegensatz zu den Cross-Compilern früher oder früher andere Plattformen.

Laufzeitbibliotheken wie Mono bieten Kompatibilität für querkompilierte .NET-Programme mit anderen Betriebssystemen wie Linux .

Bibliotheken wie Qt und seine Vorgänger, einschließlich XVT, bieten Cross-Development-Fähigkeiten auf Quellcodeebene mit anderen Plattformen, während sie weiterhin Microsoft C verwenden, um die Windows-Versionen zu erstellen. Andere Compiler wie MinGW sind in diesem Bereich ebenfalls populär geworden, da sie direkter mit den Unixen kompatibel sind, die die Nicht-Windows-Seite der Softwareentwicklung umfassen und es diesen Entwicklern ermöglichen, alle Plattformen mit einer vertrauten Build-Umgebung anzusprechen.

Frei Pascal

Free Pascal wurde von Anfang an als Cross-Compiler entwickelt. Die ausführbare Compiler-Datei (ppcXXX, wobei XXX eine Zielarchitektur ist) ist in der Lage, ausführbare Dateien (oder nur Objektdateien, wenn kein interner Linker vorhanden ist, oder sogar nur Assembly-Dateien, wenn kein interner Assembler vorhanden ist) für alle Betriebssysteme derselben Architektur zu erzeugen. ppc386 kann beispielsweise ausführbare Dateien für i386-linux, i386-win32, i386-go32v2 (DOS) und alle anderen Betriebssysteme erstellen (siehe ). Für das Kompilieren in eine andere Architektur muss jedoch zuerst eine architekturübergreifende Version des Compilers erstellt werden. Die resultierende ausführbare Compiler-Datei hätte zusätzliches 'ross' vor der Zielarchitektur in ihrem Namen. dh wenn der Compiler auf x64 ausgerichtet ist, dann wäre die ausführbare Datei ppcrossx64.

Um für ein gewähltes Architektur-OS zu kompilieren, kann der Compilerschalter (für den Compilertreiber fpc) -P und -T verwendet werden. Dies geschieht auch beim Cross-Compilieren des Compilers selbst, wird aber über die Make-Option CPU_TARGET und OS_TARGET gesetzt. GNU-Assembler und -Linker für die Zielplattform ist erforderlich, wenn Free Pascal noch keine interne Version der Tools für die Zielplattform hat.

Klingeln

Clang ist nativ ein Cross-Compiler. Zur Build-Zeit können Sie auswählen, auf welche Architekturen Clang abzielen soll.

Siehe auch

Verweise

Externe Links