Wenn Sie beim Erstellen des LFS-Systems Fragen haben oder wenn Sie einen (Rechtschreib-) Fehler im Buch finden, dann lesen Sie bitte die FAQ (Frequently Asked Questions - häufig gestellte Fragen) unter http://www.linuxfromscratch.org/faq/.

Der linuxfromscratch.org-Server stellt einige Mailinglisten für die Entwicklung des LFS-Projektes bereit. Unter anderem befinden sich dort auch die Entwickler- und Support-Mailinglisten.

Welche Listen es gibt, wie Sie eine Liste abonnieren können, wo Sie die Archive finden und vieles mehr erfahren Sie unter http://www.linuxfromscratch.org/mail.html.

Viele Mitglieder der LFS-Gemeinschaft bieten Hilfe auf unserem IRC-Server an. Bevor Sie hier Hilfe suchen, möchten wir Sie bitten, zumindest die LFS-FAQ und die Archive unserer Mailinglisten nach einer Antwort auf Ihre Frage zu durchsuchen. Der IRC-Server ist zu erreichen unter irc.linuxfromscratch.org oder irc.linux-phreak.net. Der Support-Chatraum heist #LFS-support.

Alle Mailinglisten von linuxfromscratch.org sind auch über das NNTP-Protokoll verfügbar. Alle E-Mails an die Mailinglisten werden in die dazugehörige Newsgruppe kopiert und umgekehrt.

Der News-Server ist erreichbar unter news.linuxfromscratch.org.

Weitere Informationen zu Paketen, neueren Versionen, Einstellmöglichkeiten, persönliche Erfahrungen und vieles mehr finden Sie in unserem LFS-Wiki unter http://wiki.linuxfromscratch.org/. Sie können dort auch eigene Informationen hinzufügen und auf diese Weise anderen Benutzern helfen.

Weitere Informationen zu Paketen und nützliche Tipps finden Sie unter http://www.linuxfromscratch.org/~matthew/LFS-references.html.

Das LFS-Projekt hat viele Softwarespiegel über die ganze Welt verteilt, die die Website zur Verfügung stellen und den Download der benötigten Programme vereinfachen. Bitte besuchen Sie http://www.linuxfromscratch.org/, um eine Liste der aktuellen Softwarespiegel einzusehen.

Bitte senden Sie alle Fragen und Kommentare direkt an eine der LFS-Mailinglisten (siehe oben).

Neben einer kurzen Zusammenfassung des Problems ist es wichtig, dass Sie uns noch folgende Dinge mitteilen:

Hinweis

Beachten Sie: Nur weil Sie möglicherweise von den Anweisungen im Buch abgewichen sind, bedeutet das längst nicht, dass wir Ihnen nicht helfen werden. Es ist ein Grundsatz von LFS, die Wahl zu haben. Ihr Hinweis hilft uns lediglich, mögliche Ursachen für Ihr Problem besser erkennen zu können.

Wenn beim Durchlaufen der configure-Skripte ein Problem auftritt, schauen Sie erst einmal in die Datei config.log. Diese Datei enthält viele Fehlermeldungen, die auf dem Bildschirm sonst nicht angezeigt werden. Geben Sie diese Fehlermeldungen mit an, wenn Sie um Hilfe bitten.

Um Ihnen zu helfen, sind sowohl Bildschirmausgaben als auch die Inhalte verschiedener Dateien nützlich. Die Ausgaben des ./configure-Skriptes und die des make-Befehls können sehr hilfreich sein. Bitte kopieren Sie nicht einfach blindlings die gesamte Ausgabe; auf der anderen Seite sollte es aber auch nicht zu wenig sein. Als Beispiel für sinnvolle Informationen soll Ihnen folgende Bildschirmausgabe von make helfen:

gcc -DALIASPATH=\"/mnt/lfs/usr/share/locale:.\"
-DLOCALEDIR=\"/mnt/lfs/usr/share/locale\" 
-DLIBDIR=\"/mnt/lfs/usr/lib\"
-DINCLUDEDIR=\"/mnt/lfs/usr/include\" -DHAVE_CONFIG_H -I. -I.
-g -O2 -c getopt1.c
gcc -g -O2 -static -o make ar.o arscan.o commands.o dir.o 
expand.o file.o function.o getopt.o implicit.o job.o main.o 
misc.o read.o remake.o rule.o signame.o variable.o vpath.o 
default.o remote-stub.o version.o opt1.o
-lutil job.o: In function `load_too_high':
/lfs/tmp/make-3.79.1/job.c:1565: undefined reference 
to `getloadavg'
collect2: ld returned 1 exit status
make[2]: *** [make] Error 1
make[2]: Leaving directory `/lfs/tmp/make-3.79.1'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/lfs/tmp/make-3.79.1'
make: *** [all-recursive-am] Error 2

In diesem Beispielfall kopieren viele leider nur den unteren Teil:

make [2]: *** [make] Error 1

Das reicht für uns aber nicht, um Ihnen bei der Fehlerdiagnose helfen zu können, denn es sagt uns nur, dass etwas schiefgelaufen ist, aber nicht was. Der ganze oben gezeigte Abschnitt sollte angegeben werden, denn er enthält das ausgeführte Kommando und die dazugehörige Fehlermeldung(en).

Eric S. Raymond hat zu diesem Thema einen sehr guten Artikel geschrieben. Sie finden ihn unter http://catb.org/~esr/faqs/smart-questions.html. Lesen und befolgen Sie bitte seine Tipps in dem Dokument. So erhöhen Sie Ihre Chance, dass Sie auf Ihre Frage eine Antwort erhalten, mit der Sie auch etwas anfangen können.

Viele Pakete enthalten eine Testsuite. Abhängig von der Wichtigkeit eines Paketes empfehlen wir Ihnen, die Testsuite durchlaufen zu lassen. Manchmal erzeugen die Pakete Fehlermeldungen oder unerwartete Ergebnisse. Falls Sie solchen Problemen begegnen, können Sie im LFS-Wiki unter http://wiki.linuxfromscratch.org/ nachsehen, ob diese Probleme bereits bekannt sind und untersucht wurden. Wenn das Problem bereits bekannt ist, brauchen Sie sich im Normalfall keine weiteren Sorgen machen.

Fast alle Programme führen neben ihrer eigentlichen Aufgabe noch einige sehr typische, manchmal völlig triviale Dinge aus. Das beinhaltet das Reservieren von Speicher, Durchsuchen von Ordnern, Lesen und Schreiben von Dateien, Verarbeitung von Zeichenketten, Mustersuche, Arithmetik und viele andere Dinge. Anstatt Programme zu zwingen, das "Rad neu zu erfinden", stellt das GNU System alle diese Basisfunktionen in fertigen Bibliotheken zur Verfügung. Die wichtigste dieser Bibliotheken auf jedem Linux-System ist die Glibc.

Es gibt zwei elementare Wege, wie man Funktionen einer Bibliothek in ein Programm einbinden kann—statisch oder dynamisch. Beim statischen Linken eines Programmes wird der Kode der genutzten Funktionen in die ausführbare Datei eingebettet; das resultiert in einem relativ großen und klobigen ausführbaren Programm. Beim dynamischen Linken eines Programmes wird in der ausführbaren Datei nur eine Referenz auf den dynamischen Linker, den Namen der Bibliothek und den Namen der Funktion eingebettet; daraus ergibt sich eine wesentlich kleinere ausführbare Datei. (Ein dritter möglicher Weg besteht darin, die Programmierschnittstelle des dynamischen Linkers zu benutzen. Schauen Sie für weitere Informationen bitte in die Manpage von dlopen.)

Dynamisches Linken ist unter Linux die Voreinstellung und hat drei große Vorteile gegenüber dem statischen Linken. Erstens braucht man nur eine Kopie des ausführbaren Kodes, anstelle vieler Kopien des selben Kodes, die in allen möglichen ausführbaren Dateien eingebunden sind -- nebenbei spart das auch Speicherplatz auf der Festplatte. Zweitens: Benutzen mehrere Programme die gleichen Bibliotheksfunktionen gleichzeitig, so wird dennoch nur eine Kopie der Funktion geladen -- das spart Arbeitsspeicher. Drittens: Wenn in einer Bibliotheksfunktion ein Fehler behoben wird oder sie auch einfach nur verbessert/erweitert wird, müssen Sie nur diese eine Bibliothek neu kompilieren und nicht jedes Programm, das diese Funktion benutzt.

Wenn der dynamische Linker so viele Vorteile hat, warum werden die ersten beiden Pakete in diesem Kapitel dann statisch gelinkt? Das hat drei Gründe—historische, den Lerneffekt und technische Hintergründe. Historische Gründe deshalb, weil in früheren LFS-Versionen alle Pakete in diesem Kapitel statisch verlinkt wurden. Lerntechnische Gründe, weil es Sinn macht, den Unterschied zu kennen. Technische, weil Sie durch diesen Schritt noch einen Schritt unabhängiger vom Host-System werden. Das bedeutet, diese Programme können unabhängig vom Host-System eingesetzt werden. Natürlich könnten Sie auch dann noch ein gut funktionierendes LFS-System erstellen, wenn diese Pakete dynamisch gelinkt werden.

Binutils ist eine Sammlung von Software-Entwicklungswerkzeugen, zum Beispiel Linker, Assembler und weitere Programme für die Arbeit mit Objektdateien.

Es ist wichtig, dass Binutils als erstes Paket kompiliert wird, weil Glibc und GCC verschiedene Tests bezüglich Linker und Assembler durchführen und erst daraufhin bestimmte Funktionen aktivieren.

Dieses Paket funktioniert nicht gut, wenn nicht die Standard Optimierungseinstellungen (inklusive der Optionen -march und -mcpu) benutzt werden. Deshalb sollten eventuell gesetzte Umgebungsvariablen, die die Standardoptimierung überschreiben - zum Beispiel CFLAGS und CXXFLAGS - für den Kompiliervorgang zurückgesetzt oder entsprechend abgeändert werden.

Die Dokumentation zu Binutils empfiehlt, Binutils ausserhalb des Quellordners zu kompilieren:

mkdir ../binutils-build
cd ../binutils-build

Hinweis

Wenn die im Buch angegebenen SBU-Werte einen Nutzen haben sollen, müssen Sie nun die Zeit messen, die Sie zum Kompilieren dieses Pakets benötigen. Dies können Sie relativ einfach mit folgendem Kommando tun: time { ./configure ... && ... && ... && make install; }.

Bereiten Sie Binutils zum Kompilieren vor:

../binutils-2.15.91.0.2/configure --prefix=/tools \
    --disable-nls

Die Bedeutung der configure-Parameter:

Fahren Sie mit dem Kompilieren des Pakets fort:

make configure-host
make LDFLAGS="-all-static"

Die Bedeutung der make-Parameter:

Der Kompiliervorgang ist nun abgeschlossen. Normalerweise würden Sie nun die Testsuite durchlaufen lassen, aber in diesem frühen Stadium ist die Testsuite-Umgebung (Tcl, Expect und DejaGNU) noch nicht verfügbar. Ausserdem macht es wenig Sinn die Tests nun laufen zu lassen, weil die Programme aus dem ersten Durchlauf sehr bald durch die aus dem zweiten Durchlauf ersetzt werden.

Installieren Sie das Paket:

make install

Bereiten Sie nun den Linker auf die späteren „Anpassungen“ vor:

make -C ld clean
make -C ld LDFLAGS="-all-static" LIB_PATH=/tools/lib

Die Bedeutung der make-Parameter:

Warnung

Entfernen Sie die Binutils Kompilier- und Quellordner noch nicht. Sie benötigen Sie später in ihrem jetzigen Zustand.

Details zu diesem Paket finden Sie in „Inhalt von Binutils“

Das Paket GCC enthält die GNU-Compiler-Sammlung, die auch die C- und C++-Compiler beinhaltet.

Entpacken Sie nur den GCC-core Tarball; Sie brauchen zunächst weder den C++-Compiler noch die Testsuite.

Dieses Paket funktioniert nicht gut, wenn nicht die Standard Optimierungseinstellungen (inklusive der Optionen -march und -mcpu) benutzt werden. Deshalb sollten eventuell gesetzte Umgebungsvariablen, die die Standardoptimierung überschreiben - zum Beispiel CFLAGS und CXXFLAGS - für den Kompiliervorgang zurückgesetzt oder entsprechend abgeändert werden.

Die GCC-Dokumentation empfiehlt, GCC nicht im Quellordner sondern in einem gesonderten Ordner zu kompilieren:

mkdir ../gcc-build
cd ../gcc-build

Bereiten Sie GCC zum Kompilieren vor:

../gcc-3.4.1/configure --prefix=/tools \
    --libexecdir=/tools/lib --with-local-prefix=/tools \
    --disable-nls --enable-shared --enable-languages=c

Die Bedeutung der configure-Parameter:

Fahren Sie mit dem Kompilieren des Pakets fort:

make BOOT_LDFLAGS="-static" bootstrap

Die Bedeutung der make-Parameter:

Der Kompiliervorgang ist nun abgeschlossen. Normalerweise würden Sie nun die Testsuite durchlaufen lassen, aber in diesem frühen Stadium ist die Testsuite-Umgebung (Tcl, Expect und DejaGNU) noch nicht verfügbar. Ausserdem macht es wenig Sinn, die Tests nun laufen zu lassen, weil die Programme aus dem ersten Durchlauf sehr bald durch die aus dem zweiten Durchlauf ersetzt werden.

Installieren Sie das Paket:

make install

Zum Abschluss erstellen Sie noch einen symbolischen Link. Viele Programme benutzen das Kommando cc anstelle von gcc; Das dient dem Zweck, die Programme generisch zu halten, damit sie auf verschiedenen Unix-Systemen verwendbar sind. Nicht jedes System hat den GNU C-Compiler installiert. Der Aufruf von cc lässt dem Administrator die Wahl, welchen C-Compiler er installieren möchte, solange ein symbolischer Link auf den echten Compiler verweist:

ln -s gcc /tools/bin/cc

Details zu diesem Paket finden Sie in „Inhalt von GCC“

Das Linux-Libc-Header-Paket enthält die „bereinigten“ Header-Dateien des Linux-Kernels

Über Jahre hinweg war es gängige Praxis, die „rohen“ Kernel-Header (direkt aus dem Kernel-Archiv) in /usr/include zu benutzen. Aber in den letzten Jahren haben die Kernel-Entwickler die Haltung eingenommen, dass man dies nicht tun sollte. Daraus entstand das Projekt Linux-Libc-Header. Es wurde entworfen um eine konsistente Kernel-Header Programmierschnittstelle (API) zu bewahren.

Installieren Sie die Header-Dateien:

cp -R include/asm-i386 /tools/include/asm
cp -R include/linux /tools/include

Wenn Sie keine i386-Architektur verwenden, passen Sie den Befehl entsprechend an.

Details zu diesem Paket finden Sie in „Inhalt von Linux-Libc-Header“

Das Linux-Kernel-Paket enthält die Kernel-Quellen und die von Glibc verwendeten Header-Dateien.

Da einige Pakete die Kernel Header referenzieren, entpacken Sie nun das Kernelarchiv, konfigurieren es und kopieren die benötigten Dateien an eine Stelle, wo gcc sie später finden kann.

Bereiten Sie die Installation der Header vor:

make mrproper

Hierdurch wird sichergestellt, dass der Kernel-Baum absolut sauber ist. Das Kernel-Team empfiehlt, dieses Kommando vor jedem Kompilieren des Kernels auszuführen. Sie sollten sich nicht darauf verlassen, dass die Quellen nach dem Entpacken sauber sind.

Erstellen Sie die Datei include/linux/version.h:

make include/linux/version.h

Erstellen Sie den plattformspezifischen symbolischen Link include/asm:

make include/asm

Installieren Sie die plattformspezifischen Header-Dateien:

mkdir /tools/glibc-kernheaders
cp -HR include/asm /tools/glibc-kernheaders
cp -R include/asm-generic /tools/glibc-kernheaders

Installieren Sie die Multiplattform-Headerdateien:

cp -R include/linux /tools/glibc-kernheaders

Details zu diesem Paket finden Sie in „Inhalt von Linux“

Glibc enthält die C-Bibliothek. Sie stellt Systemaufrufe und grundlegende Funktionen zur Verfügung (z. B. das Zuweisen von Speicher, Durchsuchen von Ordnern, Öffnen und Schließen sowie Schreiben von Dateien, Zeichenkettenverarbeitung, Mustererkennung, Arithmetik etc.)

Dieses Paket funktioniert nicht gut, wenn nicht die Standard Optimierungseinstellungen (inklusive der Optionen -march und -mcpu) benutzt werden. Deshalb sollten eventuell gesetzte Umgebungsvariablen, die die Standardoptimierung überschreiben - zum Beispiel CFLAGS und CXXFLAGS - für den Kompiliervorgang zurückgesetzt oder entsprechend abgeändert werden.

Grundsätzlich gilt; weichen Sie von dem in diesem Buch beschriebenen Weg zum Kompilieren von Glibc ab, dann riskieren Sie die Stabilität Ihres gesamten LFS-Systems.

Die Glibc-Dokumentation empfiehlt, nicht im Quellordner sondern in einem gesonderten Ordner zu kompilieren:

mkdir ../glibc-build
cd ../glibc-build

Als nächstes bereiten Sie Glibc zum Kompilieren vor:

../glibc-2.3.4-20040701/configure --prefix=/tools \
    --disable-profile --enable-add-ons=nptl --with-tls \
    --with-__thread --enable-kernel=2.6.0 \
    --with-binutils=/tools/bin --without-gd --without-cvs \
    --with-headers=/tools/glibc-kernheaders

Die Bedeutung der configure-Parameter:

Während dieser Phase sehen Sie möglicherweise eine Warnung:

Das fehlende oder inkompatible Programm msgfmt ist normalerweise harmlos, aber manchmal kann es zu Fehlern beim Durchlaufen der Testsuite führen. msgfmt ist Teil des Paketes Gettext, welches auf dem Host-System installiert sein sollte. Wenn msgfmt zwar vorhanden, aber vollkommen inkompatibel ist, dann sollten Sie das Paket auf dem Host-System aktualisieren. Oder Sie fahren ohne das Paket fort und schauen, ob die Testsuite auch ohne es problemlos durchläuft.

Kompilieren Sie das Paket:

make

Der Kompiliervorgang ist nun abgeschlossen. Wie bereits erwähnt, wird empfohlen, die Testsuite für das temporäre System in diesem Kapitel nicht durchlaufen zu lassen. Falls Sie die Testsuite dennoch laufen lassen möchten, führen Sie dieses Kommando aus:

make check

Eine Information über die wichtigen Fehler finden Sie in „Glibc-2.3.4-20040701“

Die Glibc Testsuite ist sehr stark von einigen Funktionen Ihres Host-Systems abhängig. Glibc-Fehler in diesem Kapitel sind normalerweise nicht so schlimm. Erst in Kapitel 6 wird die endgültige Glibc installiert, dort sollten dann die meisten Tests erfolgreich durchlaufen. Allerdings können selbst in Kapitel 6 noch Fehler auftreten, zum Beispiel beim math-Test.

Wenn ein Fehler auftritt, notieren Sie ihn, dann rufen Sie make check erneut auf. Die Testsuite sollte dann dort fortfahren, wo sie unterbrochen wurde. Sie können dieses Stoppen und Starten umgehen, indem Sie make -k check aufrufen. Aber stellen Sie in diesem Fall sicher, dass Sie die Ausgaben protokollieren, damit Sie später die Logdatei nach den aufgetretenen Fehlern durchsuchen können.

Auch wenn es nur eine harmlose Nachricht ist, die Installationsroutine von Glibc wird sich über die fehlende Datei /tools/etc/ld.so.conf beschweren. Beheben Sie diese störende Warnung mit:

mkdir /tools/etc
touch /tools/etc/ld.so.conf

Installieren Sie das Paket:

make install

Verschiedene Länder und Kulturen haben auch unterschiedliche Konventionen zum Kommunizieren. Darunter sind einfache Konventionen wie zum Beispiel das Format für Datum und Uhrzeit, aber auch sehr komplexe Konventionen, wie zum Beispiel die dort gesprochene Sprache. Die „Internationalisierung“ von GNU-Programmen funktioniert mit Hilfe der sogenannten Locales. Installieren Sie nun die Glibc-Locales.

Hinweis

Wenn Sie, wie empfohlen, die Testsuite in diesem Kapitel nicht laufen lassen, brauchen Sie auch die Locales nicht zu installieren. Sie werden sie dann im nächsten Kapitel installieren.

Wenn Sie die Glibc-Locales dennoch installieren möchten, führen Sie dieses Kommando aus:

make localedata/install-locales

Als Alternative zu dem vorigen Kommando können Sie auch nur die von Ihnen benötigten oder gewünschten Locales installieren. Das erreichen Sie mit dem Kommando localedef. Informationen dazu finden Sie in der Datei INSTALL in den Quellen zu Glibc. Jedoch gibt es einige Locales, die essentiell für die Tests von weiteren Paketen sind, im einzelnen die libstdc++ Tests von GCC. Die folgenden Anweisungen anstelle des oben verwendeten Targets install-locales installieren einen minimalen Satz von Locales, die notwendig sind, um die nachfolgenden Tests erfolgreich durchführen zu können:

mkdir -p /tools/lib/locale
localedef -i de_DE -f ISO-8859-1 de_DE
localedef -i de_DE@euro -f ISO-8859-15 de_DE@euro
localedef -i en_HK -f ISO-8859-1 en_HK
localedef -i en_PH -f ISO-8859-1 en_PH
localedef -i en_US -f ISO-8859-1 en_US
localedef -i es_MX -f ISO-8859-1 es_MX
localedef -i fa_IR -f UTF-8 fa_IR
localedef -i fr_FR -f ISO-8859-1 fr_FR
localedef -i fr_FR@euro -f ISO-8859-15 fr_FR@euro
localedef -i it_IT -f ISO-8859-1 it_IT
localedef -i ja_JP -f EUC-JP ja_JP

Details zu diesem Paket finden Sie in „Inhalt von Glibc“

Das Tcl Paket enthält die Tool Command Language.

Dieses und die nächsten beiden Pakete werden nur installiert, damit Sie die Testsuites von GCC und Binutils laufen lassen können. Drei Pakete nur zu Testzwecken zu installieren könnte etwas übertrieben erscheinen, aber es ist wirklich sehr wichtig zu wissen, dass unsere allerwichtigsten Programme und Werkzeuge richtig funktionieren. Selbst wenn wir die Testsuites in diesem Kapitel nicht ausführen (wie empfohlen), werden diese Pakete doch zumindest für die Tests im nächsten Kapitel 6 benötigt.

Bereiten Sie Tcl zum Kompilieren vor:

cd unix
./configure --prefix=/tools

Kompilieren Sie das Paket:

make

Wenn Sie die Testsuite ausführen möchten, führen Sie TZ=UTC make test aus. Es ist jedoch bekannt, dass die Testsuite von Tcl unter bestimmten Bedingungen fehlschlägt. Daher sind Fehler in der Testsuite nicht überraschend; wir betrachten diese Fehler nicht als kritisch. Der Parameter TZ=UTC setzt die Zeitzone für die Dauer des Durchlaufs der Testsuite auf Coordinated Universal Time (UTC), auch als Greenwhich Mean Time (GMT) bekannt. Dadurch werden zeitbezogene Tests korrekt ausgewertet. Mehr Informationen zu der Umgebungsvariable TZ finden Sie später in Kapitel 7.

Installieren Sie das Paket:

make install

Warnung

Sie sollten den Quellordner tcl8.4.7 noch nicht entfernen, weil das nächste Paket die internen Header-Dateien benötigt.

Erstellen Sie einen nötigen symbolischen Link:

ln -s tclsh8.4 /tools/bin/tclsh

Das Paket Expect führt vorprogrammierte Dialoge mit anderen interaktiven Programmen aus.

Spielen Sie erst einen Patch ein; dieser behebt einen Fehler, der ansonsten Fehlalarme beim Durchlaufen der GCC Testsuite verursachen könnte:

patch -Np1 -i ../expect-5.42.1-spawn-1.patch

Bereiten Sie nun Expect zum Kompilieren vor:

./configure --prefix=/tools --with-tcl=/tools/lib --with-x=no

Die Bedeutung der configure-Parameter:

Kompilieren Sie das Paket:

make

Wenn Sie die Testsuite durchlaufen lassen möchten, führen Sie das Kommando make test aus. Es ist jedoch bekannt, dass die Testsuite in diesem Kapitel Probleme macht, die noch nicht ganz nachvollzogen wurden. Es ist daher nicht überraschend, wenn die Testsuite Fehler meldet, diese werden jedoch nicht als kritisch betrachtet.

Installieren Sie das Paket:

make SCRIPTS="" install

Die Bedeutung des make-Parameters:

Sie können nun die Quellordner von Tcl und Expect entfernen.

Das Paket DejaGnu enthält ein Grundgerüst zum Testen anderer Programme.

Bereiten Sie DejaGNU zum Kompilieren vor:

./configure --prefix=/tools

Kompilieren und installieren Sie das Paket:

make install

Dieses Paket funktioniert nicht gut, wenn nicht die Standard Optimierungseinstellungen (inklusive der Optionen -march und -mcpu) benutzt werden. Deshalb sollten eventuell gesetzte Umgebungsvariablen, die die Standardoptimierung überschreiben - zum Beispiel CFLAGS und CXXFLAGS - für den Kompiliervorgang zurückgesetzt oder entsprechend abgeändert werden.

Die Hilfsmittel zum Testen von GCC und Binutils sind nun installiert (Tcl, Expect und DejaGNU). Sie können GCC und Binutils nun erneut installieren, gegen die neue Glibc verlinken und testen. Eine Sache muss noch beachtet werden: Die Testsuites sind stark von funktionierenden Pseudo-Terminals (PTYs) abhängig. Diese werden vom Host-System bereitgestellt. Heutzutage werden PTYs meist über das Dateisystem devpts implementiert. Ob Ihr Host-System korrekt eingerichtet ist, können Sie mit einem einfachen Test feststellen:

expect -c "spawn ls"

Das Ergebnis könnte so aussehen:

The system has no more ptys.  
Ask your system administrator to create more.

Wenn Sie die obige Meldung sehen, ist Ihr Host-System nicht korrekt für PTYs eingerichtet. Solange Sie dieses Problem nicht behoben haben, brauchen Sie die Testsuites von GCC und Binutils gar nicht erst durchlaufen zu lassen. Wenn Sie mehr Informationen zum Einrichten von PTYs brauchen, schauen Sie am besten in das LFS-Wiki unter http://wiki.linuxfromscratch.org/.

Diesmal kompilieren Sie sowohl den C- als auch den C++-Compiler. Entpacken Sie die GCC core- und g++- Tarballs (und -testsuite, falls Sie die Testsuite durchlaufen lassen möchten). Die Archive entpacken sich in einen einzigen Unterordner namens gcc-3.4.1/.

Zuerst korrigieren Sie ein Problem und nehmen eine wichtige Anpassung vor:

patch -Np1 -i ../gcc-3.4.1-no_fixincludes-1.patch
patch -Np1 -i ../gcc-3.4.1-specs-1.patch

Der erste Patch schaltet das fixincludes-Skript von GCC ab. Wir haben das vorher bereits kurz erwähnt; hier wollen wir eine nähere Erklärung dazu geben. Unter normalen Umständen durchsucht GCC's fixincludes-Skript Ihr System nach zu reparierenden Header-Dateien. Dabei kann es vorkommen, dass das Skript der Meinung ist, einige Header-Dateien auf Ihrem Host-System müssten repariert werden. GCC repariert diese dann und kopiert sie in den privaten GCC Include-Ordner. Später dann, in Kapitel 6, nachdem Sie die neuere Glibc installiert haben, würde dieser private Include-Ordner vor den System Include-Ordnern durchsucht werden. GCC würde dann die reparierten Include-Dateien des Host-Systems finden, und diese passen dann höchstwahrscheinlich nicht zu der Glibc-Version, die Sie für das LFS-System verwendet haben.

Der zweite Patch ändert den GCC-Standardpfad zum dynamischen Linker (üblicherweise ld-linux.so.2). Ausserdem entfernt er /usr/include aus dem Include-Suchpfad von GCC. Das Patchen an dieser Stelle statt des nachträglichen Anpassens der specs-Datei stellt sicher, dass beim Kompilieren von GCC unser neuer dynamischer Linker verwendet wird. Das bedeutet, dass alle endgültigen (und auch temporären) Binärdateien beim Kompiliervorgang gegen die neue Glibc gelinkt werden.

Wichtig

Diese Patches sind zwingende Voraussetzung für einen erfolgreichen Gesamtdurchlauf. Sie dürfen nicht vergessen, sie zu installieren!

Erstellen Sie erneut einen eigenen Ordner zum Kompilieren:

mkdir ../gcc-build
cd ../gcc-build

Denken Sie daran, vor dem Kompilieren von GCC alle Umgebungsvariablen zurückzusetzen, die die Standard-Optimierungen überschreiben würden.

Bereiten Sie GCC zum Kompilieren vor:

../gcc-3.4.1/configure --prefix=/tools \
    --libexecdir=/tools/lib --with-local-prefix=/tools \
    --enable-clocale=gnu --enable-shared \
    --enable-threads=posix --enable-__cxa_atexit \
    --enable-languages=c,c++ --disable-libstdcxx-pch

Die Bedeutung der neuen configure-Optionen:

Kompilieren Sie das Paket:

make

Diesmal müssen Sie nicht das bootstrap-Target verwenden, weil Sie bereits einen Compiler benutzen, der aus exakt den gleichen Quellen gebaut wurde.

Der Kompiliervorgang ist nun abgeschlossen. Wie bereits erwähnt, empfehlen wir, die Testsuite für das temporäre System in diesem Kapitel nicht durchlaufen zu lassen. Falls Sie die Testsuite dennoch laufen lassen möchten, führen Sie dieses Kommando aus:

make -k check

Der Schalter -k lässt die Testsuite bis zum Ende durchlaufen, selbst wenn Fehler auftreten sollten. Die Testsuite von GCC ist sehr umfangreich und es ist beinahe sicher, dass Fehler auftreten. Um eine Zusammenfassung der Ergebnisse zu erhalten, benutzen Sie dieses Kommando:

../gcc-3.4.1/contrib/test_summary

Wenn Sie nur die Zusammenfassungen sehen möchten, pipen Sie die Ausgabe durch grep -A7 Summ.

Sie können Ihre Ergebnisse mit denen in der gcc-testresults-Mailingliste veröffentlichten vergleichen, die eine ähnliche System-Konfiguration wie Sie haben. Ein Beispiel wie GCC-3.4.1 auf i686-pc-linux-gnu aussehen sollte, finden Sie unter http://gcc.gnu.org/ml/gcc-testresults/2004-07/msg00179.html.

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. 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

Hinweis

An diesem Punkt wird dringend empfohlen, die Gesamtprüfung, die Sie früher in diesem Kapitel gemacht haben, noch einmal zu wiederholen. Schlagen Sie im „Anpassen der Toolchain“ nach und wiederholen Sie die Prüfung. Wenn die Ergebnisse nicht in Ordnung sind, haben Sie höchstwahrscheinlich vergessen, den oben erwähnten GCC Specs-Patch einzuspielen.

Details zu diesem Paket finden Sie in „Inhalt von GCC“

Binutils ist eine Sammlung von Software-Entwicklungswerkzeugen, zum Beispiel Linker, Assembler und weitere Programme für die Arbeit mit Objektdateien.

Dieses Paket funktioniert nicht gut, wenn nicht die Standard Optimierungseinstellungen (inklusive der Optionen -march und -mcpu) benutzt werden. Deshalb sollten eventuell gesetzte Umgebungsvariablen, die die Standardoptimierung überschreiben - zum Beispiel CFLAGS und CXXFLAGS - für den Kompiliervorgang zurückgesetzt oder entsprechend abgeändert werden.

Erstellen Sie erneut einen eigenen Ordner zum Kompilieren:

mkdir ../binutils-build
cd ../binutils-build

Bereiten Sie Binutils zum Kompilieren vor:

../binutils-2.15.91.0.2/configure --prefix=/tools \
    --enable-shared --with-lib-path=/tools/lib

Die Bedeutung der neuen configure-Option:

Kompilieren Sie das Paket:

make

Der Kompiliervorgang ist nun abgeschlossen. Wie bereits erwähnt, wird empfohlen, die Testsuite für das temporäre System in diesem Kapitel nicht durchlaufen zu lassen. Falls Sie die Testsuite dennoch laufen lassen möchten, führen Sie dieses Kommando aus:

make check

Installieren Sie das Paket:

make install

Nun bereiten Sie Binutils auf das erneute Anpassen der Toolchain im nächsten Kapitel vor:

make -C ld clean
make -C ld LIB_PATH=/usr/lib:/lib

Warnung

Entfernen Sie die Binutils Quell- und Kompilierordner jetzt noch nicht. Sie brauchen sie im jetzigen Zustand noch im nächsten Kapitel.

Details zu diesem Paket finden Sie in „Inhalt von Binutils“

Gawk ist eine Implementierung von awk und wird zur Textmanipulation verwendet.

Bereiten Sie Gawk zum Kompilieren vor:

./configure --prefix=/tools

Kompilieren Sie das Paket:

make

Um das Ergebnis zu prüfen (nicht unbedingt nötig), führen Sie das Kommando make check aus.

Installieren Sie das Paket:

make install

Details zu diesem Paket finden Sie in „Inhalt von Gawk“

Das Paket Coreutils enthält eine große Anzahl an Shell-Werkzeugen zum Einstellen der grundlegenden Systemeigenschaften.

Bereiten Sie Coreutils zum Kompilieren vor:

DEFAULT_POSIX2_VERSION=199209 ./configure --prefix=/tools

Dieses Paket hat ein Problem, wenn es mit neueren Glibc-Versionen als 2.3.2 kompiliert wird. Einige der Coreutils-Werkzeuge (wie z. B. head, tail, und sort) lehnen ihre traditionelle Syntax ab; eine Syntax, die allerdings bereits seit ca. 30 Jahren verwendet wird. Die alte Syntax ist so eingebürgert, dass hier die Kompatibilität bewahrt werden sollte, bis die neue Syntax überall übernommen wurde. Rückwärtskompatibilität kann durch das Setzen der Umgebungsvariable DEFAULT_POSIX2_VERSION auf „199209“ erreicht werden. Wenn Sie keine Rückwärtskompatibilität wünschen, lassen Sie die Variable einfach weg. Dann müssen Sie allerdings mit den Konsequenzen leben: Viele Pakete müssen gepatcht werden, damit sie mit der neuen Syntax klar kommen. Wir empfehlen, die oben angegebenen Anweisungen so zu übernehmen.

Kompilieren Sie das Paket:

make

Wenn Sie die Testsuite durchlaufen lassen möchten, führen Sie dieses Kommando aus: make RUN_EXPENSIVE_TESTS=yes check. Der Parameter RUN_EXPENSIVE_TESTS=yes teilt der Testsuite mit, noch zusätzliche Tests zu durchlaufen, die auf einigen Plattformen sehr zeitintensiv sein können. Normalerweise ist das unter Linux aber kein Problem.

Installieren Sie das Paket:

make install

Details zu diesem Paket finden Sie in „Inhalt von Coreutils“

Das Paket Bzip2 enthält Programme zum Komprimieren und Dekomprimieren von Dateien. Bei Textdateien wird eine wesentlich bessere Kompressionsrate als mit dem traditionellen Kommando gzip erreicht.

Das Paket Bzip2 enthält kein configure-Skript. Kompilieren Sie es einfach:

make

Installieren Sie das Paket:

make PREFIX=/tools install

Details zu diesem Paket finden Sie in „Inhalt von Bzip2“

Das Paket Gzip enthält Programme zum Komprimieren und Dekomprimieren von Dateien.

Bereiten Sie Gzip zum Kompilieren vor:

./configure --prefix=/tools

Kompilieren Sie das Paket:

make

Dieses Paket enthält keine Testsuite.

Installieren Sie das Paket:

make install

Details zu diesem Paket finden Sie in „Inhalt von Gzip“

Die Programme dieses Pakets können Unterschiede zwischen Dateien oder Ordnern anzeigen.

Bereiten Sie Diffutils zum Kompilieren vor:

./configure --prefix=/tools

Kompilieren Sie das Paket:

make

Dieses Paket enthält keine Testsuite.

Installieren Sie das Paket:

make install

Details zu diesem Paket finden Sie in „Inhalt von Diffutils“

Das Paket Findutils enthält Programme zum Auffinden von Dateien, entweder durch rekursive Suche in einer Ordnerstruktur oder über den Zugriff auf eine Datenbank (was häufig schneller ist, aber die Gefahr birgt, dass die Datenbank nicht den aktuellen Zustand wiederspiegelt).

Bereiten Sie Findutils zum Kompilieren vor:

./configure --prefix=/tools

Kompilieren Sie das Paket:

make

Um das Ergebnis zu prüfen, führen Sie das Kommando make check aus.

Installieren Sie das Paket:

make install

Details zu diesem Paket finden Sie in „Inhalt von Findutils“

Das Paket Make enthält Programme zum Kompilieren umfangreicher Pakete.

Bereiten Sie Make zum Kompilieren vor:

./configure --prefix=/tools

Kompilieren Sie das Paket:

make

Um das Ergebnis zu prüfen, führen Sie das Kommando make check aus.

Installieren Sie das Paket:

make install

Details zu diesem Paket finden Sie in „Inhalt von Make“

Das Paket Grep enthält Programme zum Durchsuchen von Dateien.

Bereiten Sie Grep zum Kompilieren vor:

./configure --prefix=/tools \
    --disable-perl-regexp --with-included-regex

Die Bedeutung der configure-Parameter:

Kompilieren Sie das Paket:

make

Um das Ergebnis zu prüfen, führen Sie das Kommando make check aus.

Installieren Sie das Paket:

make install

Details zu diesem Paket finden Sie in „Inhalt von Grep“

Das Paket Sed enthält einen Stream-Editor.

Bereiten Sie Sed zum Kompilieren vor:

./configure --prefix=/tools

Kompilieren Sie das Paket:

make

Um das Ergebnis zu prüfen, führen Sie das Kommando make check aus.

Installieren Sie das Paket:

make install

Details zu diesem Paket finden Sie in „Inhalt von Sed“

Gettext wird zur Übersetzung und Lokalisierung verwendet. Programme können mit sogenanntem Native Language Support (NLS, Unterstützung für die lokale Sprache) kompiliert werden. Dadurch können Texte und Nachrichten in der Sprache des Anwenders ausgegeben werden.

Bereiten Sie Gettext zum Kompilieren vor:

./configure --prefix=/tools --disable-libasprintf \
    --disable-csharp

Die Bedeutung der configure-Parameter:

Kompilieren Sie das Paket:

make

Wenn Sie die Testsuite durchlaufen lassen möchten, führen Sie dieses Kommando aus: make check. Die Gettext Testsuite braucht sehr viel Zeit (ca. 7 SBU). Es ist bekannt, dass die Gettext Testsuite in diesem Kapitel unter verschiedenen Bedingungen fehlschlägt -- zum Beispiel, wenn Sie einen Java-Compiler auf dem Host-System findet. Ein experimenteller Patch zum Deaktivieren von Java ist aus dem LFS-Patches-Projekt unter http://www.linuxfromscratch.org/patches/ verfügbar.

Installieren Sie das Paket:

make install

Details zu diesem Paket finden Sie in „Inhalt von Gettext“

Das Paket Ncurses enthält Bibliotheken für den Terminal-unabhängigen Zugriff auf Textbildschirme.

Bereiten Sie Ncurses zum Kompilieren vor:

./configure --prefix=/tools --with-shared \
    --without-debug --without-ada --enable-overwrite

Die Bedeutung der configure-Parameter:

Kompilieren Sie das Paket:

make

Dieses Paket enthält keine Testsuite.

Installieren Sie das Paket:

make install

Details zu diesem Paket finden Sie in „Inhalt von Ncurses“

Das Paket Patch enthält ein Programm zum Modifizieren von Dateien.

Bereiten Sie Patch zum Kompilieren vor:

CPPFLAGS=-D_GNU_SOURCE ./configure --prefix=/tools

Die Präprozessor-Option -D_GNU_SOURCE wird nur auf der PowerPC-Plattform benötigt. Auf anderen Architekturen können Sie sie weglassen.

Kompilieren Sie das Paket:

make

Dieses Paket enthält keine Testsuite.

Installieren Sie das Paket:

make install

Details zu diesem Paket finden Sie in „Inhalt von Patch“

Das Paket Tar enthält ein Archivprogramm.

Bereiten Sie Tar zum Kompilieren vor:

./configure --prefix=/tools

Kompilieren Sie das Paket:

make

Um das Ergebnis zu prüfen, führen Sie das Kommando make check aus.

Installieren Sie das Paket:

make install

Details zu diesem Paket finden Sie in „Inhalt von Tar“

Das Paket Texinfo enthält Programme zum Lesen, Schreiben und Konvertieren von Info-Dokumenten (Systemdokumentation).

Bereiten Sie Texinfo zum Kompilieren vor:

./configure --prefix=/tools

Kompilieren Sie das Paket:

make

Um das Ergebnis zu prüfen, führen Sie das Kommando make check aus.

Installieren Sie das Paket:

make install

Details zu diesem Paket finden Sie in „Inhalt von Texinfo“

Das Paket Bash enthält die Bourne-Again-SHell.

Bereiten Sie Bash zum Kompilieren vor:

./configure --prefix=/tools --without-bash-malloc

Die Bedeutung der configure-Option:

Kompilieren Sie das Paket:

make

Zum Testen der Ergebnisse führen Sie dieses Kommando aus: make tests.

Installieren Sie das Paket:

make install

Und erstellen Sie einen Link für die Programme, die sh als Shell benutzen:

ln -s bash /tools/bin/sh

Details zu diesem Paket finden Sie in „Inhalt von Bash“

M4 enthält einen Makroprozessor.

Bereiten Sie M4 zum Kompilieren vor:

./configure --prefix=/tools

Kompilieren Sie das Paket:

make

Um das Ergebnis zu prüfen, führen Sie das Kommando make check aus.

Installieren Sie das Paket:

make install

Details zu diesem Paket finden Sie in „Inhalt von M4“

Bison erstellt ein Programm, das die Struktur einer Textdatei analysiert.

Bereiten Sie Bison zum Kompilieren vor:

./configure --prefix=/tools

Kompilieren Sie das Paket:

make

Um das Ergebnis zu prüfen, führen Sie das Kommando make check aus.

Installieren Sie das Paket:

make install

Details zu diesem Paket finden Sie in „Inhalt von Bison“

Das Programm Flex wird benutzt um Programme zu erzeugen, die Muster in Texten erkennen können.

Flex enthält einige bekannte Fehler. Beheben Sie diese mit dem folgenden Patch:

patch -Np1 -i ../flex-2.5.31-debian_fixes-2.patch

Die GNU autotools werden feststellen, dass die Quellen zu Flex durch den vorigen Patch manipuliert wurden und versuchen, die Hilfeseiten entsprechend zu aktualisieren. Das schlägt jedoch auf vielen Systemen fehl, und die voreingestellte Hilfeseite ist vollkommen in Ordnung. Daher stellen Sie sicher, dass die Manpage nicht neu erzeugt wird:

touch doc/flex.1

Bereiten Sie Flex nun zum Kompilieren vor:

./configure --prefix=/tools

Kompilieren Sie das Paket:

make

Um das Ergebnis zu prüfen, führen Sie das Kommando make check aus.

Installieren Sie das Paket:

make install

Details zu diesem Paket finden Sie in „Inhalt von Flex“

Das Paket Util-linux enthält verschiedene Werkzeuge. Darunter befinden sich Programme zum Umgang mit Dateisystemen, Konsolen, Partitionen und (System-)Nachrichten.

Util-linux verwendet nicht die gerade frisch installierten Header und Bibliotheken im Ordner /tools. Das korrigieren Sie durch Anpassen des configure-Skriptes:

sed -i 's@/usr/include@/tools/include@g' configure

Bereiten Sie Util-linux zum Kompilieren vor:

./configure

Kompilieren Sie einige unterstützende Routinen:

make -C lib

Da Sie nur ein paar ausgewählte Werkzeuge aus diesem Paket benötigen, kompilieren Sie auch nur diese:

make -C mount mount umount
make -C text-utils more

Dieses Paket enthält keine Testsuite.

Nun kopieren Sie diese Programme in unseren temporären Ordner tools:

cp mount/{,u}mount text-utils/more /tools/bin

Details zu diesem Paket finden Sie in „Inhalt von Util-linux“

Das Paket Perl enthält die Skriptsprache Perl (Practical Extraction and Report Language).

Zuerst müssen Sie mit dem folgenden Patch ein paar festeingestellte Pfade zur C-Bibliothek anpassen:

patch -Np1 -i ../perl-5.8.5-libc-1.patch

Bereiten Sie Perl nun zum Kompilieren vor (passen Sie auf, dass Sie 'IO Fcntl POSIX' richtig schreiben—es sind alles Buchstaben):

./configure.gnu --prefix=/tools -Dstatic_ext='IO Fcntl POSIX'

Die Bedeutung der configure-Option:

Kompilieren Sie nur ein paar benötigte Programmteile:

make perl utilities

Auch wenn Perl eine Testsuite enthält, sollte sie zum jetzigen Zeitpunkt noch nicht ausgeführt werden. Es wurden nur Teile von Perl installiert und das Ausführen von make test würde bewirken, dass nun der Rest von Perl kompiliert werden würden. Das ist zu diesem Zeitpunkt völlig unnötig, die Testsuite kann im nächsten Kapitel ausgeführt werden.

Kopieren Sie diese Werkzeuge und ihre Bibliotheken an die richtige Stelle:

cp perl pod/pod2man /tools/bin
mkdir -p /tools/lib/perl5/5.8.5
cp -R lib/* /tools/lib/perl5/5.8.5

Details zu diesem Paket finden Sie in „Inhalt von Perl“

Das Paket Udev enthält Programme zum dynamischen Erzeugen von Gerätedateien.

Das Programm udevstart hat den Pfad zu udev fest einkompiliert, was zu Problemen führt, weil udev an einem anderem Ort installiert wurde. Beheben Sie das Problem indem Sie dieses Kommando ausführen:

sed -i 's@/sbin/udev@/tools/sbin/udev@g' udevstart.c

Stellen Sie ausserdem sicher, dass udev den korrekten Pfad zu seinen Konfigurationsdateien kennt:

sed -i 's@/etc@/tools/etc@g' etc/udev/udev.conf.in

Nun kompilieren Sie Udev:

make prefix=/tools etcdir=/tools/etc

Dieses Paket enthält keine Testsuite.

Installieren Sie das Paket:

make DESTDIR=/tools udevdir=/dev install

Die voreingestellte Konfiguration von Udev ist alles andere als optimal, daher installieren Sie LFS-spezifische Konfigurationsdateien:

cp ../udev-config-2.permissions \
    /tools/etc/udev/permissions.d/00-lfs.permissions
cp ../udev-config-1.rules /tools/etc/udev/rules.d/00-lfs.rules

Details zu diesem Paket finden Sie in „Inhalt von Udev“

Unsere Ordnerstruktur basiert auf dem FHS-Standard (verfügbar unter http://www.pathname.com/fhs/). Zusätzlich zu den oben erstellten Ordnern sieht dieser Standard auch die Existenz von /usr/local/games und /usr/share/games vor, aber diese möchten wir in einem Basis-System eigentlich nicht haben. Wenn Sie möchten, können Sie Ihr System natürlich vollständig FHS-konform machen. Zur Struktur in /usr/local/share macht FHS keine präzisen Angaben, daher haben wir die Ordner erstellt, die wir für nötig halten.

Beim Booten des Kernel müssen ein paar wenige Gerätedateien vorhanden sein, im einzelnen console und null. Erstellen Sie die Gerätedateien mit diesen Kommandos:

mknod -m 600 /dev/console c 5 1
mknod -m 666 /dev/null c 1 3

Der Ideale Weg, /dev zu bestücken, ist, ramfs genau wie tmpfs in /dev einzuhängen und die Gerätedateien bei jedem Bootvorgang zu erzeugen. Weil das System aber noch nicht gebootet wurde, müssen Sie das tun, was sonst die Bootskripte erledigen würden und auf diese Weise /dev bestücken. Hängen Sie nun /dev ein:

mount -n -t ramfs none /dev

Führen Sie nun das installierte Programm udevstart aus, um die ersten Gerätedateien auf Basis von /sys zu installieren:

/tools/sbin/udevstart

LFS benötigte einige symbolische Links und Ordner die nicht von Udev erzeugt werden. Erstellen Sie diese nun:

ln -s /proc/self/fd /dev/fd
ln -s /proc/self/fd/0 /dev/stdin
ln -s /proc/self/fd/1 /dev/stdout
ln -s /proc/self/fd/2 /dev/stderr
ln -s /proc/kcore /dev/core
mkdir /dev/pts
mkdir /dev/shm

Schließlich hängen Sie das korrekte virtuelle (Kernel-) Dateisystem in die frisch erzeugten Ordner ein:

mount -t devpts -o gid=4,mode=620 none /dev/pts
mount -t tmpfs none /dev/shm

Das obige mount-Kommando könnte diese Warnmeldung ausgeben:

can't open /etc/fstab: No such file or directory.

Diese Datei—/etc/fstab—wurde bisher noch nicht erstellt, wird aber auch nicht benötigt um die Dateisysteme korrekt einzuhängen. Daher kann die Warnung problemlos ignoriert werden.

Das Linux-Libc-Header-Paket enthält die „bereinigten“ Header-Dateien des Linux-Kernels

Über Jahre hinweg war es gängige Praxis, die „rohen“ Kernel-Header (direkt aus dem Kernel-Archiv) in /usr/include zu benutzen. Aber in den letzten Jahren haben die Kernel-Entwickler die Haltung eingenommen, dass man dies nicht tun sollte. Daraus entstand das Projekt Linux-Libc-Header. Es wurde entworfen um eine konsistente Version der Kernel-Header Programmierschnittstelle (API) zu bewahren.

Installieren Sie die Header-Dateien:

cp -R include/asm-i386 /usr/include/asm
cp -R include/linux /usr/include

Stellen Sie sicher, dass die Header im Besitz von root sind:

chown -R root:root /usr/include/{asm,linux}

Stellen Sie sicher, dass normale Benutzer Leserechte auf die Header haben:

find /usr/include/{asm,linux} -type d -exec chmod 755 {} \;
find /usr/include/{asm,linux} -type f -exec chmod 644 {} \;

Das Paket Man-pages enthält über 1.200 Hilfetexte.

Installieren Sie die Man-pages durch Ausführen von:

make install

Glibc enthält die C-Bibliothek. Sie stellt Systemaufrufe und grundlegende Funktionen zur Verfügung (z. B. das Zuweisen von Speicher, Durchsuchen von Ordnern, Öffnen und Schließen sowie Schreiben von Dateien, Zeichenkettenverarbeitung, Mustererkennung, Arithmetik etc.)

Dieses Paket funktioniert nicht gut, wenn nicht die Standard Optimierungseinstellungen (inklusive der Optionen -march und -mcpu) benutzt werden. Deshalb sollten eventuell gesetzte Umgebungsvariablen, die die Standardoptimierung überschreiben - zum Beispiel CFLAGS und CXXFLAGS - für den Kompiliervorgang zurückgesetzt oder entsprechend abgeändert werden.

Das Installationssystem der Glibc ist sehr eigenständig und installiert perfekt, selbst wenn die specs-Datei unseres Compilers und der Linker immer noch auf /tools verweisen. Sie können die specs-Datei und den Linker nicht vor der Installation von Glibc modifizieren, weil die Glibc Autoconf-Tests dann falsche Resultate ergeben würden.

Die Glibc-Dokumentation empfiehlt, nicht im Quellordner sondern in einem gesonderten Ordner zu kompilieren:

mkdir ../glibc-build
cd ../glibc-build

Bereiten Sie Glibc zum Kompilieren vor:

../glibc-2.3.4-20040701/configure --prefix=/usr \
    --disable-profile --enable-add-ons=nptl --with-tls \
    --with-__thread --enable-kernel=2.6.0 --without-cvs \
    --libexecdir=/usr/lib/glibc \
    --with-headers=/tools/glibc-kernheaders

Die Bedeutung der neuen configure-Option:

Kompilieren Sie das Paket:

make

Wichtig

Die Testsuite von Glibc in diesem Abschnitt wird als absolut kritisch betrachtet. Sie sollten diesen Schritt unter keinen Umständen überspringen.

Testen Sie das Ergebnis:

make check

Die Glibc Testsuite ist sehr stark von einigen Funktionen Ihres Host-Systems abhängig, insbesondere dem Kernel. Grundsätzlich wird erwartet, dass die Glibc-Testsuite fehlerfrei durchläuft. Nichtsdestotrotz können Fehler unter bestimmten Umständen manchmal nicht vermieden werden. Hier ist eine Liste der uns allgemein bekannten Probleme:

Auch wenn es nur eine harmlose Nachricht ist, die Installationsroutine von Glibc wird sich über die fehlende Datei /etc/ld.so.conf beschweren. Beheben Sie diese störende Warnung mit:

touch /etc/ld.so.conf

Installieren Sie das Paket:

make install

Die Locales wurden durch das obige Kommando nicht installiert. Holen Sie das nach:

make localedata/install-locales

Als Alternative zu dem vorigen Kommando können Sie auch nur die von Ihnen benötigten oder gewünschten Locales installieren. Das erreichen Sie mit dem Kommando localedef. Informationen dazu finden Sie in der Datei INSTALL in den Quellen zu Glibc. Jedoch gibt es einige Locales, die essentiell für die Tests von weiteren Paketen sind, im einzelnen die libstdc++ Tests von GCC. Die folgenden Anweisungen anstelle des oben verwendeten Targets install-locales installieren einen minimalen Satz von Locales, die notwendig sind, um die nachfolgenden Tests erfolgreich durchführen zu können:

mkdir -p /usr/lib/locale
localedef -i de_DE -f ISO-8859-1 de_DE
localedef -i de_DE@euro -f ISO-8859-15 de_DE@euro
localedef -i en_HK -f ISO-8859-1 en_HK
localedef -i en_PH -f ISO-8859-1 en_PH
localedef -i en_US -f ISO-8859-1 en_US
localedef -i es_MX -f ISO-8859-1 es_MX
localedef -i fa_IR -f UTF-8 fa_IR
localedef -i fr_FR -f ISO-8859-1 fr_FR
localedef -i fr_FR@euro -f ISO-8859-15 fr_FR@euro
localedef -i it_IT -f ISO-8859-1 it_IT
localedef -i ja_JP -f EUC-JP ja_JP

Einige von make localedata/install-locales installierte Locales werden von bestimmten Anwendungen im LFS- bzw. BLFS-Buch nicht richtig unterstützt. Aufgrund der zahlreichen Probleme, die auftreten, wenn Programmierer Annahmen machen, die die Locales zerstören, sollte LFS nicht mit Locales benutzt werden, die Multi-Byte Zeichen (inklusive UTF-8) oder von-rechts-nach-links-schrift verwenden. Viele unoffizielle und instabile Patches werden benötigt, um diese Probleme in den Griff zu bekommen. Die LFS-Entwickler haben sich entschieden, solch komplexe Locales nicht zu unterstützen. Das betrifft auch die Locales ja_JP und fa_IR—sie wurden nur installiert, damit GCC und Gettext keine Probleme in den Testsuites haben. Das Programm watch aus dem Paket Procps funktioniert z. B. nicht richtig in diesen Locales. Verschiedene Versuche, diese Restriktionen zu umgehen, sind in den Tipps zur internationalisierung nachzulesen.

Erzeugen Sie die linuxthreads Man-pages, sie sind eine großartige Referenz zur Threading-Programmierschnittstelle (auch auf NPTL anwendbar):

make -C ../glibc-2.3.4-20040701/linuxthreads/man

Installieren Sie diese:

make -C ../glibc-2.3.4-20040701/linuxthreads/man install

Sie müssen die Datei /etc/nsswitch.conf erstellen, denn obwohl Glibc bei einer fehlenden oder kaputten Datei Standardwerte vorgibt, funktionieren diese Standardwerte nicht gut mit Netzwerken. Ausserdem müssen Sie die Zeitzone korrekt einstellen.

Erstellen Sie die neue Datei /etc/nsswitch.conf, indem Sie das folgende Kommando ausführen:

cat > /etc/nsswitch.conf << "EOF"
# Begin /etc/nsswitch.conf

passwd: files
group: files
shadow: files

hosts: files dns
networks: files

protocols: files
services: files
ethers: files
rpc: files

# End /etc/nsswitch.conf
EOF

Um herauszufinden, in welcher Zeitzone Sie sind, führen Sie dieses Skript aus:

tzselect

Nachdem Sie ein paar Fragen zu Ihrem Standort beantwortet haben, wird das Skript den Namen Ihrer Zeitzone ausgeben, ähnlich wie EST5EDT oder Canada/Eastern. Erstellen Sie dann die Datei /etc/localtime, indem Sie folgendes ausführen:

cp --remove-destination /usr/share/zoneinfo/[xxx] \
    /etc/localtime

Anstelle von [xxx] müssen Sie natürlich den Namen der Zeitzone einsetzen, den Ihnen tzselect ausgeben hat (z. B Canada/Eastern).

Die Bedeutung der Option zu cp:

Per Voreinstellung sucht der dynamische Lader (/lib/ld-linux.so.2) in /lib und /usr/lib nach dynamischen Bibliotheken, die von ausführbaren Programmen zur Laufzeit benötigt werden. Wenn allerdings Bibliotheken ausserhalb von /lib und /usr/lib liegen, müssen Sie diese Ordner in /etc/ld.so.conf eintragen, damit der dynamische Lader sie finden kann. Zwei Ordner sind dafür bekannt, weitere Bibliotheken zu enthalten: /usr/local/lib und /opt/lib. Fügen Sie diese Ordner in den Suchpfad ein.

Erstellen Sie die neue Datei /etc/ld.so.conf mit dem folgenden Kommando:

cat > /etc/ld.so.conf << "EOF"
# Begin /etc/ld.so.conf

/usr/local/lib
/opt/lib

# End /etc/ld.so.conf
EOF

Binutils ist eine Sammlung von Software-Entwicklungswerkzeugen, zum Beispiel Linker, Assembler und weitere Programme für die Arbeit mit Objektdateien.

Dieses Paket funktioniert nicht gut, wenn nicht die Standard Optimierungseinstellungen (inklusive der Optionen -march und -mcpu) benutzt werden. Deshalb sollten eventuell gesetzte Umgebungsvariablen, die die Standardoptimierung überschreiben - zum Beispiel CFLAGS und CXXFLAGS - für den Kompiliervorgang zurückgesetzt oder entsprechend abgeändert werden.

Jetzt ist ein guter Zeitpunkt, um zu überprüfen, dass die Pseudo-Terminals (PTYs) in Ihrer chroot-Umgebung funktionieren. Mit dem folgenden schnellen Test überprüfen Sie, ob alles korrekt eingerichtet ist:

expect -c "spawn ls"

Wenn Sie die folgende Meldung sehen, ist Ihre chroot-Umgebung nicht für PTY's vorbereitet:

The system has no more ptys.  
Ask your system administrator to create more.

Das Problem muss behoben werden, bevor Sie die Testsuites von Binutils und GCC laufen lassen.

Die Dokumentation zu Binutils empfiehlt, Binutils ausserhalb des Quellordners zu kompilieren:

mkdir ../binutils-build
cd ../binutils-build

Bereiten Sie Binutils zum Kompilieren vor:

../binutils-2.15.91.0.2/configure --prefix=/usr \
    --enable-shared

Kompilieren Sie das Paket:

make tooldir=/usr

Normalerweise ist tooldir (der Ordner, in den die ausführbaren Dateien installiert werden) auf $(exec_prefix)/$(target_alias) gesetzt, welches dann zum Beispiel zu /usr/i686-pc-linux-gnu aufgelöst wird. Da wir aber nur für unser eigenes System installieren, brauchen wir diesen speziellen Ordner in /usr nicht. Diese Konfiguration würde benutzt werden, wenn das System zum Querkompilieren genutzt würde (zum Beispiel, um auf einer Intel-Maschine Code zu generieren, der auf einem PowerPC ausgeführt werden kann).

Wichtig

Die Binutils-Testsuite in diesem Abschnitt wird als kritisch eingestuft. Wir raten Ihnen, die Tests unter keinen Umständen zu überspringen.

Testen Sie das Ergebnis:

make check

Installieren Sie das Paket:

make tooldir=/usr install

Installieren Sie die Header-Datei libiberty, sie wird von einigen Paketen benötigt:

cp ../binutils-2.15.91.0.2/include/libiberty.h /usr/include

Das Paket GCC enthält die GNU-Compiler-Sammlung, die auch die C- und C++-Compiler beinhaltet.

Dieses Paket funktioniert nicht gut, wenn nicht die Standard Optimierungseinstellungen (inklusive der Optionen -march und -mcpu) benutzt werden. Deshalb sollten eventuell gesetzte Umgebungsvariablen, die die Standardoptimierung überschreiben - zum Beispiel CFLAGS und CXXFLAGS - für den Kompiliervorgang zurückgesetzt oder entsprechend abgeändert werden.

Entpacken Sie die Archive GCC-core und GCC-g++—sie entpacken sich in den gleichen Ordner. Auf die gleiche Weise entpacken Sie bitte auch das GCC-Testsuite-Paket. Das vollständige GCC-Paket enthält noch weitere Compiler. Eine Anleitung, wie Sie diese installieren können, finden Sie unter http://www.linuxfromscratch.org/blfs/view/svn/general/gcc.html.

Vorerst installieren Sie nur den No-Fixincludes-Patch (nicht den Specs-Patch!), den Sie auch im vorigen Kapitel benutzt haben:

patch -Np1 -i ../gcc-3.4.1-no_fixincludes-1.patch

GCC hat Probleme beim Kompilieren einiger Programme, die nicht zu einer Basis-LFS-Installation gehören (z. B. Mozilla und kdegraphics), wenn GCC zusammen mit einer neuen Version von Binutils eingesetzt wird. Wenden Sie den folgenden Patch an, um das Problem zu beheben:

patch -Np1 -i ../gcc-3.4.1-linkonce-1.patch

Wenden Sie nun einen Sed-Befehl an; dadurch wird die Installation von libiberty.a verhindert. Wir möchten die von Binutils bereitgestellte Version von libiberty.a verwenden:

sed -i 's/install_to_$(INSTALL_DEST) //' libiberty/Makefile.in

Die GCC-Dokumentation empfiehlt, GCC nicht im Quellordner sondern in einem gesonderten Ordner zu kompilieren:

mkdir ../gcc-build
cd ../gcc-build

Bereiten Sie GCC zum Kompilieren vor:

../gcc-3.4.1/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

Wichtig

Die Testsuite in diesem Abschnitt wird 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

Einige Fehler sind bekannt und wurden schon im vorigen Kapitel bemerkt. Die Anmerkungen aus „GCC-3.4.1 - Durchlauf 2“ sind hier immer noch gültig. Blättern Sie zurück, wenn nötig.

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 -s ../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 -s gcc /usr/bin/cc

Hinweis

An dieser Stelle ist es wichtig, den „Gesundheitscheck“, den Sie schon früher durchgeführt haben, erneut laufen zu lassen. Schlagen Sie im „Erneutes Anpassen der Toolchain“ nach und wiederholen Sie den Test. Wenn das Ergebnis negativ ist, haben Sie möglichweise versehentlich den GCC-Specs-Patch aus Kapitel 5 angewendet.

Das Paket Coreutils enthält eine große Anzahl an Shell-Werkzeugen zum Einstellen der grundlegenden Systemeigenschaften.

Die Funktion von uname ist bekannterweise ein wenig fehlerhaft, weil der Schalter -p immer unknown ausgibt. Der folgende Patch behebt das Problem auf Intel-Architekturen:

patch -Np1 -i ../coreutils-5.2.1-uname-2.patch

Verhindern Sie, dass Coreutils Programme installiert, die später von anderen Paketen zur Verfügung gestellt werden:

patch -Np1 -i \
    ../coreutils-5.2.1-suppress_uptime_kill_su-1.patch

Bereiten Sie Coreutils zum Kompilieren vor:

DEFAULT_POSIX2_VERSION=199209 ./configure --prefix=/usr

Kompilieren Sie das Paket:

make

Diese Testsuite macht einige Annahmen in Hinsicht auf die Existenz von Benutzern und Gruppen, die in dem frühen Stadium unseres LFS-Systems noch nicht vorhanden sind. Sie müssen noch einige Dinge einrichten, bevor Sie die Tests laufen lassen können. Falls Sie diese Testsuite nicht ausführen möchten, fahren Sie mit „Installieren Sie das Paket“ fort.

Erstellen Sie zwei Dummy-Gruppen und einen Dummy-Benutzer:

echo "dummy1:x:1000:" >> /etc/group
echo "dummy2:x:1001:dummy" >> /etc/group
echo "dummy:x:1000:1000:::/bin/bash" >> /etc/passwd

Sie können die Testsuite nun durchlaufen lassen. Als erstes starten Sie einige Tests, die als root laufen müssen:

make NON_ROOT_USERNAME=dummy check-root

Die verbleibenden Tests werden als Benutzer dummy ausgeführt:

src/su dummy -c "make RUN_EXPENSIVE_TESTS=yes check"

Danach entfernen Sie die dummy Gruppen und Benutzer:

sed -i '/dummy/d' /etc/passwd /etc/group

Installieren Sie das Paket:

make install

Und verschieben Sie einige Programme an die richtige Stelle:

mv /usr/bin/{[,basename,cat,chgrp,chmod,chown,cp,dd,df} /bin
mv /usr/bin/{date,echo,false,head,hostname,install,ln} /bin
mv /usr/bin/{ls,mkdir,mknod,mv,pwd,rm,rmdir,sync} /bin
mv /usr/bin/{sleep,stty,test,touch,true,uname} /bin
mv /usr/bin/chroot /usr/sbin

Schließlich erstellen Sie noch einen symbolischen Link, um FHS-konform zu sein:

ln -s ../../bin/install /usr/bin

Zlib enthält die Bibliothek libz. Sie wird von einigen Programmen zum Komprimieren und Dekomprimieren genutzt.

Der folgende Patch behebt ein „Denial of Service“-Problem in der Zlib Kompressions-Bibliothek:

patch -Np1 -i ../zlib-1.2.1-security-1.patch

Hinweis

Vorsicht: Zlib baut seine gemeinsamen Bibliotheken falsch, wenn die Umgebungsvariable CFLAGS gesetzt ist. Wenn Sie die Umgebungsvariable CFLAGS verwenden, fügen Sie ihr für den Durchlauf von configure den Wert -fPIC an und entfernen Sie ihn später wieder.

Bereiten Sie Zlib zum Kompilieren vor:

./configure --prefix=/usr --shared

Kompilieren Sie das Paket:

make

Um das Ergebnis zu prüfen, führen Sie das Kommando make check aus.

Installieren Sie die gemeinsamen Bibliotheken:

make install

Kompilieren Sie die statische Bibliothek:

make clean
./configure --prefix=/usr
make

Um das Ergebnis zu prüfen, führen Sie das Kommando make check aus.

Installieren Sie die statische Bibliothek:

make install

Und korrigieren Sie die Zugriffsrechte auf die statische Bibliothek:

chmod 644 /usr/lib/libz.a

Wichtige gemeinsame Bibliotheken sollten in /lib installiert werden. Auf diese Weise haben Systemprogramme beim Booten, wo /usr möglicherweise noch nicht verfügbar (weil nicht eingehängt) ist, trotzdem Zugriff auf diese Bibliotheken.

Aus dem obigen Grund verschieben Sie die Laufzeitkomponenten der gemeinsamen Zlib-Bibliothek in den Ordner /lib:

mv /usr/lib/libz.so.* /lib

Korrigieren Sie den symbolischen Link /usr/lib/libz.so:

ln -sf ../../lib/libz.so.1 /usr/lib/libz.so

Das Paket Mktemp enthält Programme zum sicheren Anlegen temporärer Dateien aus Shell-Skripten heraus.

Viele Skripte verwenden immer noch das missbilligte Programm tempfile, das die gleich Funktionalität besitzt wie mktemp. Patchen Sie mktemp, damit es auch einen Wrapper für tempfile enthält:

patch -Np1 -i ../mktemp-1.5-add_tempfile-1.patch

Bereiten Sie Mktemp zum Kompilieren vor:

./configure --prefix=/usr --with-libc

Die Bedeutung der configure-Option:

Kompilieren Sie das Paket:

make

Installieren Sie das Paket:

make install
make install-tempfile

Das Paket Iana-Etc stellt Daten zu Netzwerkdiensten und Protokollen zur Verfügung.

Auffinden der Daten:

make

Installieren Sie das Paket:

make install

Das Paket Findutils enthält Programme zum Auffinden von Dateien, entweder durch rekursive Suche in einer Ordnerstruktur oder über den Zugriff auf eine Datenbank (was häufig schneller ist, aber die Gefahr birgt, dass die Datenbank nicht den aktuellen Zustand wiederspiegelt).

Bereiten Sie Findutils zum Kompilieren vor:

./configure --prefix=/usr --libexecdir=/usr/lib/locate \
    --localstatedir=/var/lib/locate

Die obige localstatedir-Anweisung ändert den Standort der locate-Datenbank wie vom FHS-Standard verlangt nach /var/lib/locate.

Kompilieren Sie das Paket:

make

Um das Ergebnis zu prüfen, führen Sie das Kommando make check aus.

Installieren Sie das Paket:

make install

Gawk ist eine Implementierung von awk und wird zur Textmanipulation verwendet.

Bereiten Sie Gawk zum Kompilieren vor:

./configure --prefix=/usr --libexecdir=/usr/lib

Kompilieren Sie das Paket:

make

Um das Ergebnis zu prüfen, führen Sie das Kommando make check aus.

Installieren Sie das Paket:

make install

Das Paket Ncurses enthält Bibliotheken für den Terminal-unabhängigen Zugriff auf Textbildschirme.

Bereiten Sie Ncurses zum Kompilieren vor:

./configure --prefix=/usr --with-shared --without-debug

Kompilieren Sie das Paket:

make

Dieses Paket enthält keine Testsuite.

Installieren Sie das Paket:

make install

Setzen Sie die Ausführungsrechte für die Ncurses-Bibliothek:

chmod 755 /usr/lib/*.5.4

Korrigieren Sie eine Bibliothek, die nicht ausführbar sein sollte:

chmod 644 /usr/lib/libncurses++.a

Verschieben Sie die Bibliotheken in den Ordner /lib, denn es wird erwartet, dass sie sich dort befinden:

mv /usr/lib/libncurses.so.5* /lib

Da die Bibliotheken verschoben wurden, zeigen ein paar symbolische Links ins Leere. Erstellen Sie diese symbolischen Links neu:

ln -sf ../../lib/libncurses.so.5 /usr/lib/libncurses.so
ln -sf libncurses.so /usr/lib/libcurses.so

Das Paket Readline enthält die Readline-Kommandozeilen-Bibliothek.

Der folgende Patch behebt ein Problem, bei dem Readline manchmal nur 33 Zeichen einer Zeile anzeigt und dann zur nächsten Zeile springt.

patch -Np1 -i ../readline-5.0-display_wrap-1.patch

Bereiten Sie Readline zum Kompilieren vor:

./configure --prefix=/usr

Kompilieren Sie das Paket:

make SHLIB_XLDFLAGS=-lncurses

Die Bedeutung der make-Option:

Installieren Sie das Paket:

make install

Vergeben Sie Readline's dynamischen Bibliotheken passendere Zugriffsrechte:

chmod 755 /usr/lib/*.5.0

Und verschieben Sie die dynamischen Bibliotheken an eine bessere Stelle:

mv /usr/lib/lib{readline,history}.so.5* /lib

Da die Bibliotheken verschoben wurden, zeigen ein paar symbolische Links ins Leere. Erstellen Sie diese symbolischen Links neu:

ln -sf ../../lib/libhistory.so.5 /usr/lib/libhistory.so
ln -sf ../../lib/libreadline.so.5 /usr/lib/libreadline.so

Das Paket Vim enthält einen sehr mächtigen Texteditor.

Tipp: Alternativen zu Vim

Wenn Sie einen anderen Editor als Vim bevorzugen—zum Beispiel Emacs, Joe oder Nano—dann schauen Sie unter http://www.linuxfromscratch.org/blfs/view/svn/postlfs/editors.html, dort finden Sie einige Installationshinweise.

Entpacken Sie zuerst beide Archivdateien—vim-6.3.tar.bz2 und (optional) vim-6.3-lang.tar.gz— in den gleichen Ordner. Dann ändern Sie den voreingestellten Pfad zu den Konfigurationsdateien vimrc und gvimrc nach /etc:

echo '#define SYS_VIMRC_FILE "/etc/vimrc"' >> src/feature.h
echo '#define SYS_GVIMRC_FILE "/etc/gvimrc"' >> src/feature.h

Bereiten Sie Vim zum Kompilieren vor:

./configure --prefix=/usr --enable-multibyte

Der optionale—aber dringend empfohlene—Parameter --enable-multibyte schaltet die Unterstützung zum Editieren von Dateien mit Multi-Byte Zeichenkodierung in vim ein. Das wird benötigt, wenn Sie ein Locale mit Multi-Byte Zeichensatz verwenden. Dieser Schalter ist auch hilfreich, wenn Sie Dateien bearbeiten möchten, die mit Distributionen wie z. B. Fedora Core erzeugt wurden. Diese Distributionen benutzen UTF-8 als voreingestellen Zeichensatz.

Kompilieren Sie das Paket:

make

Um das Ergebnis zu testen, kann das folgende Kommando verwendet werden: make test. Die Testsuite gibt jedoch jede Menge sinnlose Zeichen auf dem Bildschirm aus und könnte die Einstellungen Ihres Terminals durcheinander bringen. Das Durchlaufen dieser Testsuite ist daher ausdrücklich optional.

Installieren Sie das Paket:

make install

Viele Benutzer sind es gewöhnt, vi anstelle von vim zu starten. Damit vim gestartet wird, obwohl vi eingegeben wurde, erzeugen Sie einen symbolischen Link:

ln -s vim /usr/bin/vi

Wenn Sie später das X-Window-System auf Ihrem LFS installieren möchten, sollten Sie nach der Installation von X Ihren Vim erneut installieren. Vim bringt eine schöne grafische Oberfläche mit, die allerdings X und ein paar weitere Bibliotheken voraussetzt. Weitere Informationen finden Sie in der Vim Dokumentation und im BLFS-Buch unter http://www.linuxfromscratch.org/blfs/view/svn/postlfs/editors.html#postlfs-editors-vim.

In der Voreinstellung läuft vim im vi-inkompatiblen Modus. Das ist wahrscheinlich neu für Leute, die in der Vergangenheit andere Editoren verwendet haben. Die Einstellung „nocompatible“ ist dennoch unten aufgeführt, um daran zu erinnern, dass das neue Verhalten benutzt wird. Ausserdem wird daran erinnert, dass „compatible“ als erstes eingestellt werden muss, wenn Sie zum kompatiblen Modus wechseln möchten. Das ist nötig, weil diese Einstellung viele Parameter einstellt, und Änderungen an diesen Parametern müssen danach erfolgen, weil sie sonst keine Auswirkung hätten. Erzeugen Sie eine Standard vim-Konfigurationsdatei mit diesem Kommando:

cat > /etc/vimrc << "EOF"
" Begin /etc/vimrc

set nocompatible
set backspace=2
syntax on
if (&term == "iterm") || (&term == "putty")
  set background=dark
endif

" End /etc/vimrc
EOF

Der Parameter set nocompatible versetzt vim in einen nützlicheren Betriebsmodus (Voreinstellung) als den vi-kompatiblen Modus. Entfernen Sie das „no“ falls Sie das alte vi-Verhalten nutzen möchten. set backspace=2 erlaubt das sogenannte Backspacing über Zeilenumbrüche hinweg, automatisches Einrücken und das Starten von Einrückungen. syntax on aktiviert vims Hervorheben von Syntax. Schließlich stellt die if-Verzweigung sicher, dass mittels set background=dark die Hintergrundfarbe von bestimmten Terminals besser eingestellt ist. Dadurch wird das Hervorheben von Syntax in diesen Terminal-Emulatoren besser lesbar.

Die Dokumentation zu weiteren möglichen Optionen erhalten Sie mit diesem Kommando:

vim -c ':options'