Das Paket GCC enthält die GNU-Compiler-Sammlung. Darin sind die C- und C++-Compiler enthalten.
Wenden Sie nun einen Sed-Befehl an um die Installation von libiberty.a zu verhindern. Wir möchten die von Binutils bereitgestellte Version von libiberty.a verwenden:
sed -i 's/install_to_$(INSTALL_DEST) //' libiberty/Makefile.in
Im Bootstrap-Durchlauf aus Abschnitt 5.4, „GCC-4.0.3 - Durchlauf 1“ wurde zum Kompilieren von GCC der Compiler-Parameter -fomit-frame-pointer verwendet. Der Nicht-Bootstrap-Durchlauf verwendet diesen Parameter jedoch standardmäßig nicht. Um die Kompilier-Durchläufe von GCC konsistent zu halten, sollten Sie den Parameter für diesen Durchlauf mit dem folgenden sed-Kommando einschalten.
sed -i 's/^XCFLAGS =$/& -fomit-frame-pointer/' gcc/Makefile.in
Das Skript fixincludes versucht manchmal, die bereits installieren Header-Dateien des Systems zu "reparieren". Es ist uns allerdings bekannt, dass weder die Header von GCC-4.0.3 noch die von Glibc-2.3.6 eine Reparatur benötigen. Daher verhindern Sie den Start des fixincludes-Skriptes mit diesem Kommando:
sed -i 's@\./fixinc\.sh@-c true@' gcc/Makefile.in
GCC enthält ein Skript namens gccbug, welches zum Kompilierzeitpunkt feststellt, ob mktemp vorhanden ist. Das Ergebnis wird fest in einen bestimmten Test eingebunden. Das wiederum würde den Test dazu veranlassen, weniger sichere Zufallsnamen für temporäre Dateien zu erzeugen. Da wir mktemp später noch installieren werden, simulieren wir an dieser Stelle das Vorhandensein.
sed -i 's/@have_mktemp_command@/yes/' gcc/gccbug.in
Die Dokumentation zu GCC empfiehlt, GCC außerhalb des Quellordners zu kompilieren:
mkdir -v ../gcc-build cd ../gcc-build
Bereiten Sie GCC zum Kompilieren vor:
../gcc-4.0.3/configure --prefix=/usr \ --libexecdir=/usr/lib --enable-shared \ --enable-threads=posix --enable-__cxa_atexit \ --enable-clocale=gnu --enable-languages=c,c++
Kompilieren Sie das Paket:
make
In diesem Abschnitt wird die Testsuite als absolut kritisch betrachtet. Sie sollten diesen Schritt unter keinen Umständen überspringen.
Testen Sie die Ergebnisse, aber halten Sie bei Fehlern nicht an:
make -k check
Um eine Zusammenfassung der Testergebnisse zu sehen, verwenden Sie dieses Kommando:
../gcc-4.0.3/contrib/test_summary
Wenn Sie nur die Zusammenfassungen sehen möchten, pipen Sie die Ausgabe durch grep -A7 Summ.
Sie können die Ergebnisse mit denen unter http://www.linuxfromscratch.org/lfs/build-logs/6.2/ vergleichen.
Ein paar unerwartete Fehler lassen sich oftmals nicht vermeiden. Die Entwickler von GCC kennen diese üblicherweise bereits, hatten aber noch keine Zeit, diese Fehler zu beheben. Insbesondere die libmudflap-Tests sind aufgrund eines Fehlers ins GCC anfällig (http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20003).Kurz gesagt, solange Ihre Testergebnisse nicht grob von denen unter der obigen URL abweichen, können Sie beruhigt fortfahren.
Installieren Sie das Paket:
make install
Einige Pakete erwarten, dass der C-Präprozessor unter /lib installiert ist. Erstellen Sie daher diesen symbolischen Link:
ln -sv ../usr/bin/cpp /lib
Viele Pakete benutzen den Namen cc, um den C-Compiler aufzurufen. Um auch diesen Paketen Rechnung zu tragen, erzeugen Sie einen weiteren symbolischen Link:
ln -sv gcc /usr/bin/cc
Die endgültige Toolchain ist nun fertiggestellt. An dieser Stelle muss unbedingt erneut überprüft werden, ob Kompilieren und Linken mit ihr wie erwartet funktioniert. Wir führen den gleichen Gesundheitstest wie schon einmal in diesem Kapitel durch:
echo 'main(){}' > dummy.c cc dummy.c -Wl,--verbose &> dummy.log readelf -l a.out | grep ': /lib'
Wenn alles korrekt funktioniert, sollten keine Fehler auftreten und die Ausgabe des letzten Kommandos ist:
[Requesting program interpreter: /lib/ld-linux.so.2]
Überprüfen Sie nun, dass die korrekten Startdateien verwendet werden:
grep -o '/usr/lib.*/crt[1in].* .*' dummy.log
Wenn alles korrekt funktioniert, sollten keine Fehler auftreten und die Ausgabe des letzten Kommandos sieht so oder so ähnlich aus:
/usr/lib/gcc/i686-pc-linux-gnu/4.0.3/../../../crt1.o succeeded /usr/lib/gcc/i686-pc-linux-gnu/4.0.3/../../../crti.o succeeded /usr/lib/gcc/i686-pc-linux-gnu/4.0.3/../../../crtn.o succeeded
Stellen Sie als nächstes sicher, dass der neue Linker mit den korrekten Suchpfaden verwendet wird:
grep 'SEARCH.*/usr/lib' dummy.log |sed 's|; |\n|g'
Wenn alles korrekt funktioniert, sollten keine Fehler auftreten und die Ausgabe des letzten Kommandos sieht so oder so ähnlich aus:
SEARCH_DIR("/usr/i686-pc-linux-gnu/lib") SEARCH_DIR("/usr/local/lib") SEARCH_DIR("/lib") SEARCH_DIR("/usr/lib");
Danach prüfen Sie, ob die korrekte libc eingesetzt wird:
grep "/lib/libc.so.6 " dummy.log
Wenn alles korrekt funktioniert, sollten keine Fehler auftreten und die Ausgabe des letzten Kommandos sieht so oder so ähnlich aus:
attempt to open /lib/libc.so.6 succeeded
Und zum Schluss kontrollieren Sie noch, ob GCC den richtigen dynamischen Linker benutzt:
grep found dummy.log
Wenn alles korrekt funktioniert, sollten keine Fehler auftreten und die Ausgabe des letzten Kommandos ist:
found ld-linux.so.2 at /lib/ld-linux.so.2
Wenn Sie eine andere oder überhaupt keine Ausgabe erhalten, ist etwas ernsthaft schiefgelaufen. Sie müssen das überprüfen und alle bisherigen Schritte noch einmal nachvollziehen, um das Problem zu finden und zu beheben. Machen Sie nicht weiter, solange das Problem nicht behoben ist. Am wahrscheinlichsten ist, dass etwas beim Anpassen der specs-Datei weiter oben nicht funktioniert hat.
Wenn Sie mit dem Ergebnis zufrieden sind, löschen Sie die Testdateien:
rm -v dummy.c a.out dummy.log