6.14. GCC-4.3.2

6.14.1. Installation von GCC

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.5, „GCC-4.3.2 - 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 installierten Header-Dateien des Systems zu "reparieren". Es ist uns allerdings bekannt, dass weder die Header von GCC-4.3.2 noch die von Glibc-2.8-20080929 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

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.3.2/configure --prefix=/usr \
    --libexecdir=/usr/lib --enable-shared \
    --enable-threads=posix --enable-__cxa_atexit \
    --enable-clocale=gnu --enable-languages=c,c++ \
    --disable-bootstrap

Für andere Sprachen gelten Voraussetzungen, die an dieser Stelle nicht erfüllt sind. Im BLFS-Buch finden Sie Anleitungen zur Installation aller unterstützten Programmiersprachen von GCC.

Kompilieren Sie das Paket:

make

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.3.2/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.4/ 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 in 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 -v -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].*succeeded' 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.3.2/../../../crt1.o succeeded
/usr/lib/gcc/i686-pc-linux-gnu/4.3.2/../../../crti.o succeeded
/usr/lib/gcc/i686-pc-linux-gnu/4.3.2/../../../crtn.o succeeded

Stellen Sie sicher, dass der Compiler nach den korrekten Header-Dateien sucht:

grep -B4 '^ /usr/include' dummy.log

Dieses Kommando sollte erfolgreich mit den folgen Ausgaben beendet werden:

#include <...> search starts here:
 /usr/local/include
 /usr/lib/gcc/i686-pc-linux-gnu/4.3.2/include
 /usr/lib/gcc/i686-pc-linux-gnu/4.3.2/include-fixed
 /usr/include

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