In den HowTos gibt es einige wichtige
Informationen darüber, was man mit Make-Targets wie
menuconfig, toolchain,
precompiled, recover usw. erreichen kann beim Bau einer
Freetz-Firmware. Trotzdem gibt es im Forum regelmäßig eine Menge
Fragen zum Build-Prozess - meistens, wenn der Prozess nicht durchläuft
und der betreffende Benutzer nicht weiß, woran das liegt. Der Grund ist
meistens, dass es sich um einen unerfahrenen Benutzer handelt, der mit
GNU make keine
Erfahrung hat, weil er erstens nicht C/C++-Programmierer ist und/oder
zweitens bereits die Linux-Kommandozeile per se ein Buch mit sieben
Siegeln für ihn ist. Zumindest Ersteres trifft auf mich auch zu, und
deshalb habe ich mich mal oberflächlich eingelesen, um das Makefile
von Freetz besser (oder überhaupt) zu verstehen. Das Ergebnis meiner
Arbeit dokumentiere ich hier.
Die Probleme der Hilfesuchenden im Forum hören nämlich nicht damit auf,
dass der Build manchmal hängen bleibt. Da viele Fragen aus Sicht der
Cracks “dumm” klingen, sich häufig wiederholen - nicht jeder ist
geschickt darin, die Suchfunktion des Forums oder Google zu benutzen,
manche sind auch einfach zu faul - und somit manchen Profis lästig sind,
fallen die Antworten entsprechend kurz aus, was wiederum zu Rückfragen
und mehr “Müll” im Forum führt. Wenn dann der Hilfesuchende die
Ursache des Problems beseitigt hat (Linux-Package nachinstalliert,
richtige Option in make menuconfig
an-/abgewählt, Patch installiert),
bekommt er oftmals den Build trotzdem nicht mehr ans Laufen, weil die
Abhängigkeiten nicht hunderprozentig sauber gepflegt sind und er
zunächst nochmal ein xy-clean und/oder xy-precompiled aufrufen
müsste, ihm das aber keiner gesagt hat, weil es auch schwer
vorherzusehen ist.
Der Traum vom perfekten Makefile
, das bei jeder Dateiänderung genau
das tut, was minimal zu tun wäre, um das aktuelle Target zu bauen, ist
grundsätzlich erreichbar, bei uns aber nicht realisiert. Obwohl man
sagen muss, daß der Freetz Make-Prozess schon relativ gut ist - nur
eben nicht idiotensicher. Das war wohl auch nicht das Ziel, denn ein
“Idiot” sollte keine Firmware für seinen DSL-Router bauen wollen.
Andererseits ist es aber auch gut für unsere Gemeinschaft, wenn neuen
Mitgliedern die Lernkurve etwas angenehmer gestaltet wird. Es ergibt
keinen Sinn, dass jeder das Rad neu erfindet und sich alles selbst
erarbeitet, nur weil andere das früher hatten tun müssen.
Basis dieser Dokumentation ist Freetz-1.1.4. Da es inzwischen neuere Freetz-Versionen gibt wird an einige Stellen auf Abweichungen hingewiesen.
Das würde hier wirklich den Rahmen sprengen, daher nur ein paar Links. Sich einzulesen, lohnt sich - Bildung ist nie umsonst:
Die modifizierte Firmware wird zusammengebaut aus mehreren Komponenten:
Freetz selbst präsentiert sich nach dem Auspacken des entsprechenden
Archivs (z.B. freetz-1.1.4.tar.bz2
) entsprechend der folgenden
alphabetisch, nicht nach Wichtigkeit, sortierten Liste. (Die
Unterverzeichnisse build
, packages
, source
werden erst beim ersten
Make-Lauf erzeugt.)
make menuconfig
auswählen kann, um das
Web-Interface von Freetz mit hübschen kleinen Icons im Browser
zu versehen (werden angezeigt in der Adreßzeile und bei den
Favoriten).Makefile
im
Wurzelverzeichnis, sowie die Startskripte, cgi-Dateien und
sonstige zum Paket gehörigen Files. Die Konfigurationsdaten
enthalten auch die Versionsnummern der nach dl
herunterzuladenden Pakete.make
) liegen
dann die entsprechenden Binär- und Konfigurationsdaten, welche
ins Dateisystem eingewebt werden - zu bewundern unter
build/modified
, vgl. voriger Punkt. (ab Freetz-1.2 kommt unter
packages/ eine weitere Verzeichnis-Ebene hinzu; diese trennt
nach big oder little endian und uClibc-Version)gcc-3.4.6
) und der übrigen Targets zum
anderen (gcc-4.2.1-uClibc-0.9.28/0.9.29
). In entsprechende
Unterverzeichnisse werden die Toolchains dann auch übersetzt.
Das Bauen der Toolchains ist optional, da es vorkompilierte
Versionen zum Download gibt.
Abhängig von der Geschwindigkeit des Hosts kann der Toolchain
Bau zwischen 20 - 60 Minuten dauern.
Makefile
-Includes, welche zum Bauen der Firmware-Images bzw.
für make recover
notwendig sind. Mit den Werkzeugen werden
z.B. die Original-Firmwares entpackt (SquashFS-Dateisystem) und
die späteren Mod-Images nach dem Einweben aller Bestandteile
wieder zusammen geschnürt. Eine ältere tar-Version (15.1), die
mit den in den Original-Firmwares enthaltenen Entpackern
kompatible Firmware-Archive erzeugt, gehört neben anderen
Helferlein ebenfalls dazu.
Es dürfte allgemein bekannt sein, daß die drei wichtigsten Make-Targets
in dieser Reihenfolge aufzurufen - lauten:
make menuconfig
- interaktiv Pakete zusammenstellen, zusätzliche
Bibliotheken auswählen, Konfiguration speichernmake
- Tools bauen, Toolchains bauen (sofern kein externer
Compiler ausgewählt wurde), danach Bibliotheken, Linux-Kernel und
Packages bauen, abschließen Firmware bauen.Daneben gibt es eine beträchtliche Anzahl weiterer
Make-Targets,
die teilweise nicht direkt im Makefile sichtbar sind, sondern durch
automatisierte Ersetzungsvorgänge erzeugt werden. Das hat den Vorteil,
daß es z.B. pro Package jeweils die gleichen Sub-Targets gibt und man
somit immer die Möglichkeit hat, durch einen Make-Aufruf direkt
Einfluß auf einzelne Pakete zu nehmen (z.B. aufräumen, nochmal neu
übersetzen). Wenn also make precompiled
beispielsweise im Paket
mc hängen geblieben ist, weil ein
zum Bauen notwendiges Linux-Paket in unserer Distribution gefehlt hat,
das wir erst noch per Paketmanager installieren mussten, kann es sein,
dass ein erneuter Aufruf des globalen precompiled anschließend
trotzdem nicht durchläuft, weil es Inkonsistenzen im Package-Build gibt.
Da hilft dann meistens eine Sequenz wie make <Paket>-clean
,
make <Paket>-precompiled
, also z.B. mc-clean und mc-precompiled.
Wie die Pakete heißen, sieht man an den Namen der Unterverzeichnisse im
Verzeichnis make
.
Es gibt generell zwei Arten, Make für hierarchisch strukturierte
Builds zu benutzen. Die eine, althergebrachte, geht von einem Makefile
im Hauptverzeichnis und jeweils einem weiteren Makefile
pro
Unterverzeichnis aus. Daß dies keine gute Idee ist, wird in
Recursive Make Considered
Harmful
überzeugend dargelegt. Die gute Nachricht ist: Freetz verwendet die
zweite Methode, und zwar Include-Dateien in den Unterverzeichnissen.
D.h., das Makefile
lädt die für das aktuelle Target notwendigen
Includes dynamisch nach und erzeugt so ein einziges, großes, virtuelles
Makefile
, welches dann abgearbeitet wird. Das ist schön, führt aber
dazu, daß wir im Makefile
sehen, wie Dinge aufgerufen und abgearbeitet
werden, deren Herkunft nicht ganz so leicht festzustellen ist, wenn man
sich nicht im Detail die Verzeichnisstruktur ansieht. Ich versuche hier,
das ein wenig transparenter zu machen.
Makefile
die Konfigurationsdatei .config
im Hauptverzeichnis. Sie wiederum enthält die in make menuconfig
festgelegten Optionen für die Zusammenstellung des Firmware-Images.
Damit wird schon klar, weshalb wir make menuconfig
immer als
erstes aufrufen sollten. Die Datei existiert übrigens direkt nach
dem Auspacken des Mod-Archivs auch noch gar nicht. Ausnahme für den
Include: Sofern wir nur Targets aus der Gruppe menuconfig, config,
oldconfig, defconfig, tools bauen wollen, erfolgt kein Include an
dieser Stelle, da diese Targets ihn nicht benötigen.tools/make/Makefile.in
sowie tools/make/*.mk
, was dazu führt, daß die einzelnen
Tool-Targets (find-squashfs, lzma, squashfs, tichksum, makedevs,
fakeroot) der Variablen TOOLS hinzugefügt werden. Anschließend
wird pro Tool-Target noch eine Liste von Sub-Targets erzeugt:
Makefile
des Tools mit make clean
auf. Das Target clean
löscht meistens sämtliche generierten Dateien und Verzeichnisse,
um anschließend sauber neu aufsetzen zu können..config.cmd
dran. Dadurch werden rekursiv
Konfigurations-Schalter diverser Pakete eingelesen, die später dem
Build zur Verfügung stehen.make/pkgs/Makefile.in
,
make/pkgs/*/Makefile.in
, make/toolchain/Makefile.in
und die
entsprechenden *.mk-Dateien sorgen für noch mehr
Informationen im virtuellen Makefile
. Anschließend haben wir,
analog zu den Tools oben, folgende Targets zur Verfügung, die sich
in die Gruppen TARGETS, PACKAGES, LIBS, TOOLCHAIN aufteilen:
Makefile
des Targets mit make clean
auf. Das Target
clean löscht meistens sämtliche generierten Dateien und
Verzeichnisse, um anschließend sauber neu aufsetzen zu können.Makefile
des Packages mit make clean
auf. Das Target
clean löscht meistens sämtliche generierten Dateien und
Verzeichnisse, um anschließend sauber neu aufsetzen zu können.Makefile
der Bibliothek mit make clean
auf. Das
Target clean löscht meistens sämtliche generierten Dateien und
Verzeichnisse, um anschließend sauber neu aufsetzen zu können.Makefile
der Toolchain mit make clean
auf. Das
Target clean löscht meistens sämtliche generierten Dateien und
Verzeichnisse, um anschließend sauber neu aufsetzen zu können.Direkt im Top-Level-Makefile
, also nicht inkludiert, sind weitere
Targets enthalten.
make precompiled
)
bereits erledigt sind, kann man das Target firmware benutzen.
Es baut bei Bedarf noch die Tools (nicht mit den Toolchains zu
verwechseln) und macht sich dann ans Werk. Am Ende hat man ein
Firmware-Image im images-Verzeichnis mit dem Namen *.image. Das
Target wird implizit aufgerufen, wenn mann einfach make
aufruft,
also das Default-Target baut. Übrigens erledigt das Skript fwmod
im Wurzelverzeichnis die ganze Arbeit des Firmware-Bauens. Es ist
sicher interessant, sich dieses Skript mal im Detail anzusehen, wenn
man wissen möchte, was da so alles passiert.So, ich hoffe, dieser Artikel bringt dem einen oder anderen Modder etwas. Diskussionen, Feedback, Korrekturen hierzu sind wie immer willkommen und können im zugehörigen Forums-Thread eingebracht werden.
Alexander Kriegisch
(kriegaex)
Überarbeitet von Oliver Metz