Kreuzweise
Mit gcc einen Cross Compiler zu erstellen, ist nicht schwer. Will man jedoch eine komplette Entwicklungsumgebung zusammenbauen, gibt es einige Fußangeln zu beachten.
- Michael Riepe
Vor allem im Embedded-Umfeld spielen Cross Compiler eine wichtige Rolle. Die Zielsysteme sind in der Regel zu klein, um eine native Entwicklungsumgebung zu tragen. Das hat vor allem wirtschaftliche Gründe: Jede Komponente, die man nicht für den Betrieb benötigt, verursacht unnötige Kosten. Wer hohe Stückzahlen produziert, muss buchstäblich mit jedem Zehntelcent rechnen und mit Material knausern, wo es nur geht.
Einzelne Softwarepakete wie gcc oder binutils lassen sich mit einfachen Mitteln dazu bringen, Code für eine andere Rechnerarchitektur zu erzeugen. Dreh- und Angelpunkt ist das Konfigurationsskript configure, dem man vor dem Übersetzen erklären muss, was man wünscht. Dazu dienen die Optionen --build, --host und --target.
Erstere teilt configure mit, auf was für einem System die Übersetzung stattfindet; oft ist das Skript jedoch in der Lage, das selbst herauszufinden. Mit --host=<host> kann der Nutzer festlegen, auf welcher Rechnerarchitektur die Software laufen soll – i686-pc-linux-gnu etwa steht für einen modernen PC unter Linux. Soll der Compiler Maschinencode für ein anderes System erzeugen – also als Cross Compiler arbeiten –, muss man mit --target=<target> die Zielarchitektur einstellen, zum Beispiel sparc64-sun-solaris2. Anschließend kann man wie gewohnt make aufrufen.
Gegenseitige Abhängigkeiten
Allerdings ist es damit nicht getan. Zu einer kompletten Entwicklungsumgebung gehören außer Compiler, Assembler und Linker (Letztere sind im Paket binutils enthalten) auch Debugging-Werkzeuge, die Laufzeitbibliothek libc und eventuell andere Bibliotheken nebst den dazugehörigen Header-Dateien. Unter Linux sind zum Übersetzen außerdem die Header-Dateien des Kernels für die Zielmaschine notwendig. Will man die entwickelte Software testen, braucht man den übersetzten Kernel ebenfalls.
Abhängigkeiten zwischen den einzelnen Paketen machen das Einrichten einer kompletten Toolchain zu einer mühsamen Angelegenheit. Zum einen gilt es, beim Übersetzen die richtige Reihenfolge einzuhalten – manche Pakete muss man sogar mehrfach mit unterschiedlichen configure-Optionen übersetzen. Zum anderen muss der Nutzer die Eigenarten der Zielplattform berücksichtigen und eventuell zusätzliche Patches einspielen.
Mehr oder weniger vollständige Rezepte für einzelne Plattformen sind im Internet zu finden, etwa in den einschlägigen Entwicklerforen. Wer schnell zum Ziel kommen will, sollte jedoch die Verwendung einer vorgefertigten Backmischung in Erwägung ziehen: crosstool-NG von Yann Morin. Sie enthält abgesehen von den benötigten Quelltext-Paketen alle wichtigen Zutaten für eine Reihe unterschiedlicher Systeme, einschließlich erprobter Konfigurationen für Linux auf Alpha-, ARM-, Itanium-, Mips-, PowerPC-, x86- und x86_64-Plattformen sowie Bare-Metal-Systeme mit ARM- oder Mips-Prozessoren. Als Laufzeitbibliothek kann glibc, µClibc oder die vergleichsweise junge eglibc (Embedded Glibc) zum Einsatz kommen. Eine detaillierte Liste der getesteten Toolchains ist auf der Projekt-Homepage zu finden (siehe Kasten „Onlinequellen“). Weitere Zielplattformen und -betriebssysteme sollen folgen. Als Entwicklungssystem (Host) eignen sich Linux, Mac OS X und Windows/Cygwin.
Wer will, kann crosstool-NG wie jedes andere Softwarepaket installieren. Es lässt sich jedoch auch ohne Installation verwenden, wenn man vor dem Übersetzen ./configure mit der Option --local aufruft und später das Programm im selben Verzeichnis mit dem Kommando ./ct-ng startet.
Toolchains à la carte
Ähnlich wie beim Linux-Kernel kann der Nutzer eine neue Konfiguration mit ct-ng menuconfig menügesteuert erstellen oder mit ct-ng oldconfig aus einer vorhandenen Konfigurationsdatei übernehmen. Alternativ kann er mit ct-ng <konfiguration> eine der vorgefertigten Konfigurationen aufrufen. Das abschließende Kommando ct-ng build startet den Übersetzungsvorgang; alles Weitere geht automatisch. Das Programm lädt die benötigten Quelltext-Pakete aus dem Internet herunter – sofern man nicht einen lokalen Mirror verwendet –, packt sie aus, spielt die notwendigen Patches ein, generiert die Binaries und installiert sie im gewünschten Verzeichnis. Besitzer eines Multi-Core-Rechners können den Vorgang etwas beschleunigen, indem sie mit ct-ng build.<anzahl> mehrere Prozesse parallel arbeiten lassen.
Zu Testzwecken lässt sich der Übersetzungsvorgang an bestimmten Stellen anhalten oder fortsetzen, indem man die Environment-Variablen STOP und RESTART setzt. Ihre Werte müssen dem Namen einer der Übersetzungsphasen entsprechen. Mit ct-ng STOP=binutils etwa hält ct-ng nach dem Übersetzen der binutils an, ct-ng RESTART=binutils überspringt alle früheren Schritte. Die Liste der „Haltepunkte“ hängt von der gewählten Konfiguration ab und lässt sich mit ct-ng list-steps erfragen.
