War der letzte Vorgang fehlerfrei? Ehrlich? Wenn nicht, hat das Folgende absolut keinen Sinn! Mit dem hier wird ein weiterer Test durchgeführt. Und funktioniert der Bau von dem nächsten hier nicht, passierte ein Fehler irgendwo vorher bei Binutils, GCC oder Glibc und es macht absolut keinen Sinn, noch weiter zu machen.
Noch einmal: In diesem Paket ist ein linker, ein Assembler und eine Menge anderer Werkzeuge. Zuerst auspacken:
tar -xjf pakete/binutils-2.22.tar.bz2 && cd binutils-2.22/
Und wieder brauchen wir ein extra Verzeichnis:
mkdir -v ../binutils-build && cd ../binutils-build
und etwas an Konfiguration:
CC="$MOLLI_TGT-gcc -B/tools/lib/" \ AR=$MOLLI_TGT-ar RANLIB=$MOLLI_TGT-ranlib \ ../binutils-2.22/configure --prefix=/tools \ --disable-nls --with-lib-path=/tools/lib
Die Bedeutung der Parameter für configure:
CC="$MOLLI_TGT-gcc -B/tools/lib/"
AR=$MOLLI_TGT-ar RANLIB=$MOLLI_TGT-ranlib
Dienen dazu, weil das wirklich ein originaler Bau wird, einen Crosscompiler und die dazugehörigen Werkzeuge zu haben, wirklich ohne jeden nur denkbaren Zusammenhang mit dem Originalsystem.
--with-lib-path=/tools/lib
Soll im Skript beim Kompilieren den Weg zu den Bibliotheken weisen und ihn an den Linker weitergeben, wodurch dieser nicht weiter herumsucht.
Das Paket kompilieren:
make
Geschafft und wieder installieren:
make install
Und jetzt wird der Linker für die Phase in nächsten Kapitel nachjustiert:
make -C ld clean && make -C ld LIB_PATH=/usr/lib:/lib && cp -v ld/ld-new /tools/bin
Die Bedeutung der Parameter für make:
-C ld
clean
Damit werden alle übersetzen Programme aus dem Verzeichnis
ld entfernt.
-C ld
LIB_PATH=/usr/lib:/lib
und der Rest im selben Unterverzeichnis ld adaptiert. LIB_PATH erlaubt, die
voreingestellten Werte zu überschreiben und auf den
endgültigen Weg zu verweisen. Auch für den Linker ist der ab
jetzt gültig.
Zum Schluss noch das Verzeichnis verlassen und entfernen:
cd .. && rm -rf binutils-*