Warum Binutils als erstes? Das wurde doch schon dargelegt! Jetzt auspacken von:
tar -jxf pakete/binutils-2.22.tar.bz2 && cd binutils-2.22/
Jetzt erzeugen wir ein extra Build Verzeichnis, wird von den Binutils-Entwicklern so empfohlen und wechseln dort hinein:
mkdir -v ../binutils-build && cd ../binutils-build
Und wo sind wir jetzt? Was sagt pwd? Und warum? Weil die Dokumentation ein Kompilieren außerhalb des Quellenverzeichnisses den Benutzern ans Herz legt! Jetzt wird einmal konfiguriert:
../binutils-2.22/configure \
--target=$MOLLI_TGT --prefix=/tools \
--disable-nls --disable-werror --disable-multilib
Die Bedeutung der Parameter für configure:
--target=$MOLLI_TGT
Hatten wir schon, siehe Einführung.
--prefix=/tools
Es soll nach /tools installiert werden.
--disable-nls
Es muss jetzt nicht auch noch international sein.
--disable-werror
Jetzt wird nicht gleich bei einem Fehler angehalten.
--disable-multilib
Wir wollen nur 32bit oder nur 64bit, aber bitte nicht beides.
Und los geht es! Moment noch! Die Zeit zum Kompilieren dieses Paketes wird gern als Einheitsmaß genommen! Aber jetzt!
make
Wenn die Kompilierung abgeschlossen ist würden wir normalerweise die Tests ausführen. Dazu fehlt aber noch Software die wir erst später installieren.
Installiere nun das Paket:
make install
Wenn Du Molli auf x86_64 baust musst noch folgendes machen:
case $(uname -m) in
x86_64) ln -sv /tools/lib /tools/lib64 ;;
esac
Nun wie immer, raus aus dem Verzeichnis und löschen:
cd .. && rm -rf binutils-*
Noch ein Wort zu den Zeiten die das kompilieren benötigt. Da diese je nach Leistung des Rechners sehr unterschiedlich ausfallen werde ich sie nicht mit in das Buch aufnehmen. Aber als Anhaltspunkt kann man einen Blick in diese Dateien werfen: tools-20111031-1516-bauzeiten.log bzw. in main-20111031-bauzeiten.log. Diese stammen von einem Build auf einem Intel Core 2 Duo T7300