Ein böser Bearbeiter ist ein Bearbeiter, der dazu fähig ist, rechtskräftigen Code für eine Plattform zu schaffen, außer derjenigen, auf der der Bearbeiter geführt wird. Böse Bearbeiter-Werkzeuge werden verwendet, um executables für das eingebettete System oder die vielfachen Plattformen zu erzeugen. Es wird verwendet, um für eine Plattform zu kompilieren, auf die es nicht ausführbar ist, das Kompilieren wie Mikrokontrolleure zu tun, die kein Betriebssystem unterstützen. Es ist mehr üblich geworden, um dieses Werkzeug für die Paravirtualisierung zu verwenden, wo ein System eine oder mehr Plattformen im Gebrauch haben kann.

Nicht ins Visier genommen durch diese Definition sind Quelle Quellübersetzern, die häufig böse Bearbeiter irrtümlicherweise genannt werden.

Gebrauch von bösen Bearbeitern

Der grundsätzliche Gebrauch eines bösen Bearbeiters soll die bauen Umgebung von der Zielumgebung trennen. Das ist in mehreren Situationen nützlich:

• Eingebettete Computer, wo ein Gerät Mittel äußerst beschränkt hat. Zum Beispiel wird ein Mikrowellengerät einen äußerst kleinen Computer haben, um seinen touchpad und Tür-Sensor zu lesen, Produktion einem Digitaldisplay und Sprecher zur Verfügung zu stellen, und die Maschinerie zu kontrollieren, um Essen zu kochen. Dieser Computer wird nicht stark genug sein, um einen Bearbeiter, ein Dateisystem oder eine Entwicklungsumgebung zu führen. Seit dem Beseitigen und der Prüfung kann auch mehr Mittel verlangen, als auf einem eingebetteten System verfügbar ist, kann Quer-Kompilation weniger beteiligt und zu Fehlern weniger anfällig werden als heimische Kompilation.
• Das Kompilieren für vielfache Maschinen. Zum Beispiel könnte eine Gesellschaft mehrere verschiedene Versionen eines Betriebssystems unterstützen oder mehrere verschiedene Betriebssysteme unterstützen mögen. Durch das Verwenden eines bösen Bearbeiters baut eine Single Umgebung kann aufgestellt werden, um für jedes dieser Ziele zu kompilieren.
• Das Kompilieren auf einer Server-Farm. Ähnlich dem Kompilieren für vielfache Maschinen baut ein komplizierter, der einschließt, kompilieren viele Operationen kann über jede Maschine durchgeführt werden, die, unabhängig von seiner zu Grunde liegenden Hardware oder der Betriebssystemversion frei ist, die es führt.
• Das Urladeverfahren zu einer neuen Plattform. Wenn man Software für eine neue Plattform oder den Emulator einer zukünftigen Plattform entwickelt, verwendet man einen bösen Bearbeiter, um notwendige Werkzeuge wie das Betriebssystem und ein heimischer Bearbeiter zu kompilieren.
• Das Kompilieren heimischen Codes für Emulatoren für ältere jetzt veraltete Plattformen wie der Kommodore 64 oder Apple II durch Anhänger, die böse Bearbeiter verwenden, die auf einer aktuellen Plattform (wie das MS DOS des aztekischen C 6502 böse Bearbeiter laufen, die unter Windows XP laufen).

Der Gebrauch von virtuellen Maschinen (wie Javas JVM) löst einige der Gründe auf, aus denen böse Bearbeiter entwickelt wurden. Das virtuelle Maschinenparadigma erlaubt derselben Bearbeiter-Produktion, über vielfache Zielsysteme verwendet zu werden, obwohl das nicht immer Ideal ist, weil virtuelle Maschinen häufig langsamer sind und das kompilierte Programm nur auf Computern mit dieser virtuellen Maschine geführt werden kann.

Normalerweise unterscheidet sich die Hardware-Architektur (z.B das Kompilieren eines Programms, das für die MIPS Architektur auf einem x86 Computer bestimmt ist), aber Quer-Kompilation ist auch anwendbar, wenn sich nur die Betriebssystemumgebung, als unterscheidet, wenn sie ein Programm von FreeBSD unter Linux, oder sogar gerade der Systembibliothek, als kompiliert, wenn sie Programme mit uClibc auf einem Glibc-Gastgeber kompiliert.

Kanadisches Kreuz

Das kanadische Kreuz ist eine Technik, um böse Bearbeiter für andere Maschinen zu bauen. In Anbetracht drei Maschinen A, B, und C, verwendet man Maschine (z.B laufendes Windows XP auf einem IA-32 Verarbeiter), um einen bösen Bearbeiter zu bauen, der auf der Maschine B (z.B laufender Mac OS X auf einem x86-64 Verarbeiter) läuft, um executables für die Maschine C (z.B laufender Androide auf einem ARM-Verarbeiter) zu schaffen. Wenn es das kanadische Kreuz mit GCC verwendet, kann es vier beteiligte Bearbeiter geben:

• Der Eigentums-(beschreibt Waren, die gemacht und von einer besonderen Gesellschaft verbreitet werden, deren Name auf dem Produkt ist), heimischer Bearbeiter für die Maschine (1) (z.B Bearbeiter von Microsoft Visual Studio) wird verwendet, um den gcc heimischen Bearbeiter für die Maschine (2) zu bauen.
• Der gcc heimische Bearbeiter für die Maschine (2) wird verwendet, um den Gcc-Kreuz-Bearbeiter von der Maschine zur Maschine B (3) zu bauen
• Der Gcc-Kreuz-Bearbeiter von der Maschine zur Maschine B (3) wird verwendet, um den Gcc-Kreuz-Bearbeiter von der Maschine B zur Maschine C (4) zu bauen

Der Endergebnis-Kreuz-Bearbeiter (4) wird nicht im Stande sein, auf Ihrem zu laufen, bauen Maschine A; stattdessen würden Sie es auf der Maschine B verwenden, um eine Anwendung in den rechtskräftigen Code zu kompilieren, der dann zur Maschine C kopiert und auf der Maschine C durchgeführt würde.

Zum Beispiel stellt NetBSD einen POSIX Unix genannte Schale-Schrift zur Verfügung, der zuerst seinen eigenen toolchain mit dem Bearbeiter des Gastgebers bauen wird; das wird abwechselnd verwendet, um den Quer-Bearbeiter zu bauen, der verwendet wird, um das ganze System zu bauen.

Das kanadische Begriff-Kreuz ist geschehen, weil zurzeit, dass diese Probleme unter der Diskussion waren, Kanada drei nationale politische Parteien hatte.

Zeitleiste von frühen bösen Bearbeitern

• 1979 - Algol 68C hat ZCODE erzeugt, das hat Halten nach Backbord des Bearbeiters und anderen Algols 68 Anwendungen hinzugefügt, um Plattformen abwechseln zu lassen. Um das Algol 68C zu kompilieren, hat Bearbeiter ungefähr 120 Kilobytes des Gedächtnisses verlangt. Mit Z80 ist sein 64-Kilobyte-Gedächtnis zu klein, um wirklich den Bearbeiter zu kompilieren. So für den Z80 musste der Bearbeiter selbst kompiliert vom größeren KAPPE-Fähigkeitscomputer oder einem Großrechner von IBM 370 sein böse.

GCC und böse Kompilation

GCC, eine Sammlung der kostenlosen Software von Bearbeitern, kann aufgestellt werden, um sich zu treffen, kompilieren. Es unterstützt viele Plattformen und Sprachen.

GCC verlangt, dass eine kompilierte Kopie von binutils für jede ins Visier genommene Plattform verfügbar ist. Besonders wichtig ist der GNU-Monteur. Deshalb, binutils muss zuerst richtig mit dem an die konfigurieren Schrift gesandten Schalter kompiliert werden. GCC muss auch mit derselben Auswahl konfiguriert werden. GCC kann dann normalerweise geführt werden vorausgesetzt, dass die Werkzeuge, die binutils schafft, im Pfad verfügbar sind, der mit dem folgenden (auf UNIX ähnlichen Betriebssystemen mit dem heftigen Schlag) getan werden kann:

PFAD =/path/to/binutils/bin: $ {PFAD} macht

Kreuz, das GCC kompiliert, verlangt, dass ein Teil der C Standardbibliothek der Plattform des Ziels auf der Gastgeber-Plattform verfügbar ist. Mindestens der crt0... müssen Bestandteile der Bibliothek verfügbar sein. Sie können beschließen, die volle C Bibliothek zu kompilieren, aber das kann für viele Plattformen zu groß sein. Die Alternative soll newlib verwenden, der eine kleine C Bibliothek ist, die nur die wesentlichsten Bestandteile enthält, die erforderlich sind, C Quellcode zu kompilieren. Um GCC mit newlib zu konfigurieren, verwenden Sie den Schalter.

Die GNU-Autowerkzeug-Pakete (d. h. autoconf, machen Sie auto, und libtool) verwenden den Begriff einer bauen Plattform, einer Gastgeber-Plattform und einer Zielplattform. Die bauen Plattform besteht darin, wo der Bearbeiter wirklich kompiliert wird. In den meisten Fällen, bauen Sie sollte unbestimmt verlassen werden (es wird vom Gastgeber im Verzug sein). Die Gastgeber-Plattform besteht darin, wo die Produktionsartefakte vom Bearbeiter durchgeführt werden. Die Zielplattform wird verwendet, wenn das böse Kompilieren Bearbeiter durchquert, vertritt es, welchen Gegenstand-Code das Paket selbst erzeugen wird; sonst ist die Zielplattform-Einstellung irrelevant. Denken Sie zum Beispiel, ein Videospiel zu quer-kompilieren, das auf Dreamcast laufen wird. Die Maschine, wo das Spiel kompiliert wird, ist die Gastgeber-Plattform, während Dreamcast die Zielplattform ist.

Eine andere Methode, die von eingebetteten Entwicklern von Linux populär verwendet wird, soll GCC Bearbeiter mit Scratchbox oder dem neueren scratchbox2 verwenden. Diese Werkzeuge schaffen einen "chrooted" Sandkasten, wo Sie Ihre Werkzeuge, libc, und Bibliotheken aufbauen können, ohne Extrapfade setzen zu müssen. Es hat auch Möglichkeiten, für die Durchlaufzeit ins Denken zu beschwindeln, dass es auf (zum Beispiel) einer ARM-Zentraleinheit ist, so mögen Dinge, konfigurieren Schriften wird laufen. Die Kehrseite zu Scratchbox ist, dass es langsamer ist und die meisten Ihrer Werkzeuge, die auf dem Gastgeber sind, muss Scratchbox umgezogen werden, um zu fungieren.

Manx-Azteke C durchquert Bearbeiter

Manx Softwaresysteme, Shrewsbury, New Jersey, haben C Bearbeiter erzeugt, die in den 1980er Jahren ins Visier genommen an Berufsentwicklern für eine Vielfalt von Plattformen bis zu und einschließlich PCs und Macs beginnen.

Der Azteke von Manx C Programmiersprache war für eine Vielfalt von Plattformen einschließlich MS DOS, Apple II DOS 3.3 und ProDOS, Kommodores 64, Macintosh 68XXX und Amiga verfügbar.

Von den 1980er Jahren und im Laufe der 1990er Jahre bis weitergehend, sind Manx Softwaresysteme verschwunden, die Version des MS DOS von aztekischem C wurde beide als ein heimischer Weise-Bearbeiter oder als ein böser Bearbeiter für andere Plattformen mit verschiedenen Verarbeitern einschließlich des Kommodores 64 und Apple II angeboten. Internetvertrieb besteht noch für aztekischen C einschließlich gestützten bösen Bearbeiter ihres MS DOS. Sie sind noch im Gebrauch heute.

Der aztekische C86 von Manx, ihr heimischer Bearbeiter des MS DOS des Verfahrens 8086, war auch ein böser Bearbeiter. Obwohl es Code für einen verschiedenen Verarbeiter wie ihr aztekischer C65 6502 böse Bearbeiter für den Kommodore 64 und Apple II nicht kompiliert hat, hat es binären executables für das Dann-Vermächtnis Betriebssysteme für die 16 Bit 8086 Familie von Verarbeitern geschaffen.

Als IBM PC zuerst eingeführt wurde, war es mit einer Wahl von Betriebssystemen, BEDIENUNGSFELD/M 86 und PC-DOS verfügbar, das zwei von ihnen ist. Aztekischer C86 wurde mit Verbindungsbibliotheken versorgt, um Code für beiden IBM PC Betriebssysteme zu erzeugen. Im Laufe der 1980er Jahre haben spätere Versionen von aztekischem C86 (3.xx, 4.xx und 5.xx) Unterstützung für das MS DOS "vorübergehende" Versionen 1 und 2 hinzugefügt, und die weniger robust waren als die "Grundlinie"-Version 3 des MS DOS, und später den aztekischer C86 bis zu seiner Besitzübertragung ins Visier genommen hat.

Schließlich hat aztekischer C86 Entwickler der c Sprache mit der Fähigkeit versorgt, mit dem ROM fähigen "HEXE"-Code zu erzeugen, der dann mit einem ROM-Brenner direkt an einem 8086 gestützten Verarbeiter übertragen werden konnte. Paravirtualisierung kann heute üblicher sein, aber die Praxis, auf niedriger Stufe ROM-Code zu schaffen, war pro Kopf während jener Jahre üblicher, als sich Gerät-Fahrer Entwicklung wurde häufig von Anwendungsprogrammierern für individuelle Anwendungen und neuen Geräten getan, auf eine Heimindustrie belaufen hat. Es war für Anwendungsprogrammierer ziemlich üblich, direkt mit der Hardware ohne Unterstützung vom Hersteller zu verbinden. Diese Praxis war der Eingebetteten Systementwicklung heute ähnlich.

Thomas Fenwick und James Goodnow II waren die zwei Hauptentwickler des Azteken-C. Fenwick ist später bemerkenswert als der Autor des Microsoft Windows CE Kernel oder NK geworden ("Neuer Kern"), wie es dann genannt wurde.

Kreuz-Bearbeiter von Microsoft C

Frühe Geschichte - die 1980er Jahre

Microsoft C (MSC) hat eine lange Geschichte, die auf die 1980er Jahre zurückgeht. Der erste Microsoft C Compilers wurde von derselben Gesellschaft gemacht, die Gitter C gemacht hat und von Microsoft als ihr eigenes wiedergebrandmarkt wurde, bis MSC 4 veröffentlicht wurde, der die erste Version war, die Microsoft selbst erzeugt hat.

1987 haben viele Entwickler angefangen, auf Microsoft C umzuschalten, und noch viele würden während der Entwicklung von Windows von Microsoft zu seinem aktuellen Zustand folgen. Produkte wie Klipper und späterer Trompetenschall sind erschienen, der leichte Datenbankanwendungsentwicklung angeboten hat, indem er böse Sprachtechniken verwendet worden ist, einem Teil ihrer Programme erlaubend, mit Microsoft C kompiliert zu werden.

1987

C Programme war lange mit auf der Zusammenbau-Sprache geschriebenen Modulen verbunden worden. Die meisten C Bearbeiter (sogar aktuelle Bearbeiter) bieten einen Zusammenbau-Sprachpass an (der für die Leistungsfähigkeit gezwickt werden kann, die dann mit dem Rest des Programms nach der Versammlung verbunden ist).

Bearbeiter wie Azteke-C haben alles in die Zusammenbau-Sprache als ein verschiedener Pass umgewandelt und haben dann den Code in einem verschiedenen Pass gesammelt, und wurden für ihren sehr effizienten und kleinen Code bemerkt, aber vor 1987 war der in Microsoft C eingebaute optimizer sehr gut, und nur "Mission, als die kritische" Teile eines Programms gewöhnlich für das Neuschreiben betrachtet wurden. Tatsächlich hatte Programmierung der c Sprache als die "Tiefststand"-Sprache, mit der Programmierung des Werdens eine multidisziplinäre Wachstumsindustrie und Projekte übernommen, die größer mit Programmierern werden, die Benutzerschnittstellen und Datenbankschnittstellen auf Sprachen des höheren Niveaus schreiben, und ein Bedürfnis war für die böse Sprachentwicklung erschienen, die bis jetzt weitergeht.

Vor 1987, mit der Ausgabe von MSC 5.1, hat Microsoft eine böse Sprachentwicklungsumgebung für das MS DOS angeboten. Binärer 16-Bit-Gegenstand-Code, der auf der Zusammenbau-Sprache (MASM) und den anderen Sprachen des Microsofts einschließlich des Schnellen geschrieben ist, Grundlegend, Pascal und Fortran konnte zusammen in ein Programm in einem Prozess verbunden werden, den sie "Mischsprachprogrammierung" und jetzt "das Benennen von InterLanguage" genannt haben. Wenn GRUNDLEGEND, wurde in dieser Mischung verwendet, das Hauptprogramm musste im GRUNDLEGENDEN sein, um das innere Laufzeitsystem zu unterstützen, das GRUNDLEGEND erforderlich für die Müll-Sammlung und seine anderen geführten Operationen kompiliert hat, die einen GRUNDLEGENDEN Dolmetscher wie QBasic im MS DOS vorgetäuscht haben.

Die Benennen-Tagung für den C-Code sollte insbesondere Rahmen in der "Rückordnung" auf dem Stapel und den Rückwerten auf dem Stapel aber nicht in einem Verarbeiter-Register passieren. Es gab andere Programmierregeln, alle Sprachen zusammenarbeiten zu lassen, aber diese besondere Regel hat durch die böse Sprachentwicklung angedauert, die überall in Bit-Versionen des Windows 16 und 32 und in der Entwicklung von Programmen für OS 2 weitergegangen hat, und die bis jetzt andauert. Es ist als die Benennen-Tagung von Pascal bekannt.

Ein anderer Typ der bösen Kompilation, für die Microsoft C während dieser Zeit verwendet wurde, war in Einzelanwendungen, die tragbare Geräte wie Symbol Technologies PDT3100 verlangen (hat gepflegt, Warenbestand zu nehmen), der eine an einem 8088 gestützten Strichcodeleser ins Visier genommene Verbindungsbibliothek zur Verfügung gestellt hat. Auf die Anwendung wurde auf dem dem tragbaren Gerät dann übertragenen Gastgeber-Computer gebaut (über ein Serienkabel), wohin es geführt, dazu ähnlich wurde, was heute für diesen denselben Markt mit Windows getan wird, das von Gesellschaften wie Motorola beweglich ist, der Symbol gekauft hat.

Anfang der 1990er Jahre

Im Laufe der 1990er Jahre und mit MSC 6 (ihr erster ANSI C entgegenkommender Bearbeiter) beginnend, hat Microsoft ihre C Bearbeiter auf den erscheinenden Windows-Markt, und auch auf OS 2 und in der Entwicklung von GUI Programmen wiedereingestellt. Mischsprachvereinbarkeit ist durch MSC 6 auf der Seite des MS DOS geblieben, aber die API für Windows 3.0 und 3.1 von Microsoft wurde in MSC 6 geschrieben. MSC 6 wurde auch erweitert, um Unterstützung für 32-Bit-Bauteile und Unterstützung für erscheinendes Windows für Workgroups und Windows NT zur Verfügung zu stellen, der das Fundament für Windows XP bilden würde. Eine Programmierpraxis hat gerufen ein thunk wurde eingeführt, um zu erlauben, zwischen 16 und 32 Bit-Programmen zu gehen, die die Laufzeitschwergängigkeit (dynamische Verbindung) aber nicht die statische Schwergängigkeit ausgenutzt haben, die in monolithischen 16-Bit-Anwendungen des MS DOS bevorzugt wurde. Statische Schwergängigkeit wird noch von einigen Eingeborener-Codeentwicklern bevorzugt, aber stellt den Grad des Codewiedergebrauchs nicht allgemein zur Verfügung, der durch neuere beste Methoden wie Capability Maturity Model (CMM) erforderlich ist.

Unterstützung des MS DOS wurde noch mit der Ausgabe des ersten C des Microsofts ++ Bearbeiter, MSC 7 versorgt, der mit der C Programmiersprache und dem MS DOS rückwärts gerichtet vereinbar war und sowohl 16-bit-als auch 32-Bit-Codegeneration unterstützt hat.

MSC hat übernommen, wo aztekischer C86 aufgehört hat. Der Marktanteil für C Bearbeiter hatte sich gedreht, um Bearbeiter zu durchqueren, die die letzten und größten Windows-Eigenschaften, angebotenen C und C ++ in einem einzelnen Bündel ausgenutzt haben, und noch Systeme des MS DOS unterstützt haben, die bereits ein altes Jahrzehnt waren, und sich die kleineren Gesellschaften, die Bearbeiter wie aztekischer C erzeugt haben, nicht mehr bewerben konnten und entweder sich Nische-Märkten wie eingebettete Systeme zugewandt haben oder verschwunden sind.

MS DOS und 16-Bit-Codegenerationsunterstützung haben bis zu MSC 8.00c weitergegangen, der mit Microsoft C ++ und Microsoft Application Studio 1.5, dem Vorzeichen von Microsoft Visual Studio gestopft wurde, der die böse Entwicklungsumgebung ist, die Microsoft heute zur Verfügung stellt.

Gegen Ende der 1990er Jahre

MSC 12 wurde mit Microsoft Visual Studio 6 veröffentlicht und nicht mehr Unterstützung für 16-Bit-Dualzahlen des MS DOS zur Verfügung gestellt, stattdessen Unterstützung für 32-Bit-Konsole-Anwendungen zur Verfügung stellend, aber Unterstützung für Windows 95 und Codegeneration von Windows 98 sowie für Windows NT zur Verfügung gestellt. Verbindungsbibliotheken waren für andere Verarbeiter verfügbar, die Windows von Microsoft geführt haben; eine Praxis, die Microsoft bis jetzt fortsetzt.

MSC 13 wurde mit dem Sehstudio 2003 veröffentlicht, und MSC 14 wurde mit dem Sehstudio 2005 veröffentlicht, von denen beide noch Code für ältere Systeme wie Windows 95 erzeugen, aber der Code für mehrere Zielplattformen einschließlich des beweglichen Marktes und der ARM-Architektur erzeugen wird.

.NET und darüber hinaus

2001 hat Microsoft Common Language Runtime (CLR) entwickelt, die den Kern für ihren.NET Fachwerk-Bearbeiter im Sehstudio IDE gebildet hat. Diese Schicht auf dem Betriebssystem, das in der API ist, erlaubt das Mischen von Entwicklungssprachen, die über Plattformen kompiliert sind, die Windows Betriebssystem führen.

Die.NET Fachwerk-Durchlaufzeit und CLR stellen eine kartografisch darstellende Schicht den Kernroutinen für den Verarbeiter und die Geräte auf dem Zielcomputer zur Verfügung. Die Befehl-Linie C Bearbeiter im Sehstudio wird heimischen Code für eine Vielfalt von Verarbeitern kompilieren und kann verwendet werden, um die Kernroutinen selbst zu bauen.

Microsoft.NET Anwendungen für Zielplattformen wie auf der ARM-Architektur Bewegliches Windows quer-kompiliert auf Windows-Maschinen mit einer Vielfalt von Verarbeitern, und Microsoft bieten auch Emulatoren und entfernte Aufstellungsumgebungen an, die sehr wenig Konfiguration, verschieden von den bösen Bearbeitern in den Tagen vorbeigegangen oder auf anderen Plattformen verlangen.

Laufzeitbibliotheken, solch so Mono abspielbar, stellen Vereinbarkeit für quer-kompilierte.NET Programme zu anderen Betriebssystemen zur Verfügung wie Linux.

Bibliotheken wie Qt und seine Vorgänger einschließlich XVT versorgen Quellcodeniveau-Kreuz-Entwicklungsfähigkeit mit anderen Plattformen, während sie noch Microsoft C verwenden, um die Windows-Versionen zu bauen. Andere Bearbeiter wie MinGW sind auch populär in diesem Gebiet geworden, da sie mit Unixes mehr direkt vereinbar sind, die die Nichtwindows-Seite der Softwareentwicklung umfassen, die jenen Entwicklern erlaubt, alle Plattformen mit einem vertrauten ins Visier zu nehmen, bauen Umgebung.

Freies Pascal

Freies Pascal wurde vom Anfang als ein böser Bearbeiter entwickelt. Der Bearbeiter rechtskräftig (ppcXXX, wo XXX eine Zielarchitektur ist) ist dazu fähig, executables zu erzeugen (oder wenden Sie gerade Dateien ein, wenn kein innerer linker, oder sogar gerade Zusammenbau-Dateien besteht, wenn kein innerer Monteur besteht) für den ganzen OS derselben Architektur. Zum Beispiel ist ppc386 dazu fähig, executables für i386-linux, i386-win32, i386-go32v2 (DOS) zu erzeugen, und alle anderen OSes (sehen). Um zu einer anderen Architektur jedoch zu kompilieren, muss eine böse Architektur-Version des Bearbeiters zuerst gebaut werden. Der resultierende rechtskräftige Bearbeiter würde zusätzlichen 'ross' vor der Zielarchitektur in seinem Namen haben. d. h. wenn der Bearbeiter gebaut wird, um x64 ins Visier zu nehmen, dann würde das rechtskräftige ppcrossx64 sein.

Um für eine gewählte Architektur-OS zu kompilieren, kann der Bearbeiter-Schalter (für den Bearbeiter-Fahrer fpc)-P und-T verwendet werden. Das wird auch getan, wenn Kreuz, das den Bearbeiter selbst kompiliert, aber darüber gesetzt wird, machen Auswahl CPU_TARGET und OS_TARGET. GNU-Monteur und linker für die Zielplattform sind erforderlich, wenn Freies Pascal innere Version der Werkzeuge für die Zielplattform nicht noch hat.

Siehe auch

• Bearbeiter
• MinGW
• Scratchbox
• Freies Pascal

Links

• Böse Kompilationswerkzeuge - Verweisung, um GNU zu konfigurieren, durchquert Kompilationswerkzeuge
• Das Gebäude Bösen Toolchains mit gcc ist ein wiki anderer GCC Quer-Kompilationsverweisungen
• Scratchbox ist ein Werkzeug für die Quer-Kompilation von Linux, um SICH ZU BEWAFFNEN, und x86 nimmt ins Visier
• Grand Unified Builder (GUB) für Linux, um vielfache Architekturen z.B:Win32/Mac OS/FreeBSD/Linux verwendet vom GNU LilyPond zu quer-kompilieren
• Crosstool ist ein nützlicher toolchain von Schriften, die Linux schaffen, quer-kompilieren Umgebung für die gewünschte Architektur, einschließlich eingebetteter Systeme
• crosstool-NG ist ein Umschreiben von Crosstool und hilft Gebäude toolchains.
• buildroot ist ein anderer Satz von Schriften, für einen mit Sitz in uClibc toolchain gewöhnlich für eingebettete Systeme zu bauen. Es wird von OpenWrt verwertet.
• ELDK (eingebetteter Linux Entwicklungsbastelsatz). Verwertet durch Das U-Boot.
• T2 SDE ist ein anderer Satz von Schriften, um ganze Linux Systeme zu bauen, die entweder auf dem GNU libC, uClibc oder auf dietlibc für eine Vielfalt von Architekturen gestützt sind
• Durchqueren Sie Linux aus dem Kratzer-Projekt
• IBM hat einen sehr klaren strukturierten Tutorenkurs über das Quer-Gebäude eines GCC toolchain.

• Quer-Kompilation avec GCC 4 sous Windows gießt Linux - Ein Tutorenkurs, um ein Quer-GCC toolchain zu bauen, aber von Windows bis Linux hat ein Thema selten entwickelt