Das ist so knapp als nur irgendwie möglich und denkbar unbequem. Trotzdem muss alles zum Kompilieren vorhanden sein. Toolchain hat da Compiler, Assembler, Linker und Bibliotheken (lib) und ein paar Werkzeuge dazu. Was noch etwas von Bedeutung ist, ist der dynamische Linker. Dieser kommt mit Glibc und sucht die Bibliotheken und lädt sie, bereitet das Programm vor und führt es aus. Ein Wort noch zur Mutter, das ist das vorhandene Ding an Rechner mit einem Linux Betriebssystem, ohne das geht gar nichts. Diese Mutter hat eine Tochter namens Molli. Das ist viel klarer als im englischen IT-Kauderwelsch, wo alles "host" ist. Am Muttersystem also kann man es unter dem Verzeichnis /lib finden, oder Du rufst folgendes auf und notierst das Ergebnis von:
readelf -l <irgendeine Binärdatei> | grep interpreter
Das Kompilieren ist eigentlich ein Crosskompilieren. Durch Anpassen des Pfades für den Standard linker sollten Programme nur mit den gewünschten Bibliotheken verbunden werden und bei gcc specs-Datei erfährt der Compiler von dem gewünschten Standardlinker.
Installiert wird in $MOLLI/tools als
erstes Binutils, weil damit und mit der Konfigurationsdatei GCC und
Glibc den Assembler und den Linker testen und dabei werden gewisse
Funktionen ein- und andere ausgeschaltet. Nur so kann die Toolchain
so, wie beabsichtigt, arbeiten. Fehler können im unglücklichsten Fall
erst ganz am Ende auftreten. Binutils platziert seinen Assembler in
/tools/bin und in /tools/Zieltriplet/bin, was natürlich nicht ganz
stimmt, es ist ein harter Link!
Der Linker sucht die Bibliotheken nach einem fixen Schema. Das ist kein Geheimnis, das sieht man gleich mit der Option --verbose. Mach einfach:
ld --verbose | grep SEARCH oder noch besser gcc dummy.c -Wl,--verbose 2&1 | grep succeeded
Als nächstes nimmt man GCC und das überrascht dadurch, das es nicht laut configure-Script den Ordner PATH durchsucht, um seine Werkzeuge zu finden. Aber wollen wir den Standard linker wissen, probieren wir:
gcc -print-prog-name=ld zusammen mit gcc -v dummy.c
so erfahren wir einiges über Präprozessor. Kompilierungs- und Assemblierungsphasen und dazu die Reihenfolge der Suchpfade.
Jetzt kann man die Glibc ins Auge fassen. Das findet sein GCC laut PATH, Binutils und Kernelheaders sind da heikler. Also wird alles und jedes vorgeschrieben. Es ist empfehlenswert, config.make im Ordner glibc-build nach den Durchlauf von ./configure genau durchzusehen. Man kann da sehen, wie eigenständig Glibc ist.
Jetzt wird es aber Zeit, dass ein Suchen und Verbinden nach dem dynamischen Linker nur innerhalb von /tools/bin stattfindet. Dazu benutze man die specs-Datei von GCC und überprüft mit:
readelf -l <Name der ausführbaren Datei> | grep interpreter
Wird das nicht haargenau durchgeführt, nimmt sich GCC den Linker des Muttersystems statt den der Tochter. Wie für Binutils im zweiten Durchgang --with-lib-path, sieht man, ob das richtige ld verwendet wird. Stimmt das, kann das Tochtersystem als sauber bezeichnet werden.
Nur noch am Rande: Patches können sogar vor dem Kompilieren angewendet werden, Fehlermeldungen müssen nicht zur Panik verleiten, nach jedem Kompilieren sollte der Quell- und der Kompilierordner gesäubert werden, ohne bash wird es keinen Erfolg geben?
In Kapitel 5 wird es nicht viel Dokumentation geben, diese wird in Kapitel 6 ausführlich dargestellt. In Kapitel 5 erstellen wir uns die Werkzeuge die für das kompilieren des eigentlichen Systems notwendig sind. Die Reihenfolge ist fest vorgegeben, wer davon abweicht sollte wissen was er tut.
Und? Richtig:
echo $MOLLI
Danach wechseln wir ins Verzeichnis $MOLLI/sources
cd $MOLLI/sources