FAQ

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

IRC

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 Port 6667. Der Support Chatraum heist #LFS-support.

Mailinglisten

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.

News Server

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

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

Software Spiegel

Das LFS Projekt hat viele Software Spiegel ü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 Software Spiegel einzusehen.

Kontakt

Bitte senden sie alle Fragen und Kommentare direkt zu einer der LFS Mailinglisten (siehe oben).

Aber wenn sie Gerard Beekmans persönlich erreichen müssen, senden sie eine Email an gerard@linuxfromscratch.org.

Aktuelle Mitglieder des Projekt Teams

• Gerard Beekmans <gerard@linuxfromscratch.org> -- Linux-From-Scratch Initiator, LFS Projektbetreuer.

• Matthew Burgess <matthew@linuxfromscratch.org> -- LFS allgemeiner Pakete-Betreuer, LFS Buch Autor.

• Craig Colton <meerkats@bellsouth.net> -- LFS, ALFS, BLFS und Ersteller des Tipp-Projekt Logo.

• Jeroen Coumans <jeroen@linuxfromscratch.org> -- Website Entwickler, FAQ Betreuer.

• Bruce Dubbs <bdubbs@linuxfromscratch.org> -- LFS Kopf des Qualitätssicherungsteams, BLFS Buch Autor.

• Alex Groenewoud <alex@linuxfromscratch.org> -- LFS Buch Autor.

• Mark Hymers <markh@linuxfromscratch.org> -- CVS Betreuer, Ersteller des BLFS Buch, früherer LFS Buch Autor.

• James Iwanek <iwanek@linuxfromscratch.org> -- Mitglied des Teams für Systemadministration.

• Nicholas Leippe <nicholas@linuxfromscratch.org> -- Wiki Betreuer.

• Anderson Lizardo <lizardo@linuxfromscratch.org> -- Ersteller und Betreuer der Website-Skripte.

• Bill Maltby <bill@linuxfromscratch.org> -- LFS Projekt Organisator.

• Scot Mc Pherson <scot@linuxfromscratch.org> -- LFS NNTP Gateway Betreuer.

• Ryan Oliver <ryan@linuxfromscratch.org> -- Kopf des Test Teams, Miterschaffer des PLFS.

• James Robertson <jwrober@linuxfromscratch.org> -- Bugzilla Betreuer, Wiki Entwickler, LFS Buch Autor.

• Greg Schafer <greg@linuxfromscratch.org> -- Toolchain Betreuer, LFS Buch Autor, Miterschaffer des PLFS.

• Tushar Teredesai <tushar@linuxfromscratch.org> -- BLFS Buch Autor, Betreuer des Tipps und Patches Projekts.

• Jeremy Utley <jeremy@linuxfromscratch.org> -- LFS Buch Autor, Bugzilla Betreuer.

• Zahllose weitere Personen aus den verschiedenen LFS und BLFS Mailinglisten die mit Vorschlägen, Tests und Fehlerberichten, Anleitungen und Installationserfahrungen zu diesem Buch beitragen.

Übersetzer

• Manuel Canales Esparcia <macana@lfs-es.org> -- Spanisches LFS Übersetzerprojekt.

• Johan Lenglet <johan@linuxfromscratch.org> -- Französisches LFS Übersetzerprojekt.

• Anderson Lizardo <lizardo@linuxfromscratch.org> -- Portugiesisches LFS Übersetzerprojekt.

• Thomas Reitelbach <tr@erdfunkstelle.de> -- Deutsches LFS Übersetzerprojekt.

Softwarespiegel Betreuer

• Jason Andrade <jason@dstc.edu.au> -- au.linuxfromscratch.org Spiegel.

• William Astle <lost@l-w.net> -- ca.linuxfromscratch.org Spiegel.

• Baque <baque@cict.fr> -- lfs.cict.fr Spiegel.

• Stephan Brendel <stevie@stevie20.de> -- lfs.netservice-neuss.de Spiegel.

• Ian Chilton <ian@ichilton.co.uk> -- us.linuxfromscratch.org, linuxfromscratch.co.uk Spiegel.

• Fredrik Danerklint <fredan-lfs@fredan.org> -- se.linuxfromscratch.org Spiegel.

• David D.W. Downey <pgpkeys@aeternamtech.com> -- lfs.learnbyexample.com Spiegel.

• Eduardo B. Fonseca <ebf@aedsolucoes.com.br> -- br.linuxfromscratch.org Spiegel.

• Hagen Herrschaft <hrx@hrxnet.de> -- de.linuxfromscratch.org Spiegel.

• Tim Jackson <tim@idge.net> -- linuxfromscratch.idge.net Spiegel.

• Barna Koczka <barna@siker.hu> -- hu.linuxfromscratch.org Spiegel.

• Roel Neefs -- linuxfromscratch.rave.org Spiegel.

• Simon Nicoll <sime@dot-sime.com> -- uk.linuxfromscratch.org Spiegel.

• Ervin S. Odisho <ervin@activalink.net> -- lfs.activalink.net Spiegel.

• Guido Passet <guido@primerelay.net> -- nl.linuxfromscratch.org Spiegel.

• Mikhail Pastukhov <miha@xuy.biz> -- lfs.130th.net Spiegel.

• Jeremy Polen <jpolen@rackspace.com> -- us2.linuxfromscratch.org Spiegel.

• UK Mirror Service -- linuxfromscratch.mirror.co.uk Spiegel.

• Thomas Skyt <thomas@sofagang.dk> -- dk.linuxfromscratch.org Spiegel.

• Antonin Sprinzl <Antonin.Sprinzl@tuwien.ac.at> -- at.linuxfromscratch.org Spiegel.

• Dag Stenstad <dag@stenstad.net> für die Bereitstellung von no.linuxfromscratch.org und Ian Chilton für das Betreiben.

• Parisian sysadmins <archive@doc.cs.univ-paris8.fr> -- www2.fr.linuxfromscratch.org Spiegel.

• Jesse Tie-Ten-Quee <highos@linuxfromscratch.org> für das Bereitstellen und Betreiben des linuxfromscratch.org Server.

• Alexander Velin <velin@zadnik.org> -- bg.linuxfromscratch.org Spiegel.

• Martin Voss <Martin.Voss@ada.de> -- lfs.linux-matrix.net Spiegel.

• Pui Yong <pyng@spam.averse.net> -- sg.linuxfromscratch.org Spiegel.

Spender

• Dean Benson <dean@vipersoft.co.uk> für etliche Geldspenden.

• DREAMWVR.COM für das ehemalige Sponsoring von Ressourcen zu LFS und dazugehörigen Projekten.

• Hagen Herrschaft <hrx@hrxnet.de> für die Spende eines 2.2 GHz P4 Systems, welches nun unter dem Namen lorien läuft.

• O'Reilly für die gespendeten Bücher zu SQL und PHP.

• VA Software , die, im Namen von Linux.com, eine VA Linux 420 (früher StartX SP2) Workstation gespendet haben.

• Mark Stone für die Spende von shadowfax, dem ersten linuxfromscratch.org Server, einem 750 MHz P3 mit 512 MB RAM und zwei 9 GB SCSI Festplatten. Als der Server umgezogen wurde, wurde er in belgarath umbenannt.

• Jesse Tie-Ten-Quee <highos@linuxfromscratch.org> für die Spende eines Yamaha CDRW 8824E CD-Brenners.

• Zahllose weitere Menschen aus den verschiedenen LFS Mailinglisten die dieses Buch mit Ihren Vorschlägen, Fehlerberichten und Kritiken besser machen.

Ehemalige Team-Mitglieder und Beitragende

• Timothy Bauscher <timothy@linuxfromscratch.org> -- LFS Buch Autor, Tipps Projekt Betreuer.

• Robert Briggs für die Spende der linuxfromscratch.org und linuxfromscratch.com Domain Namen.

• Ian Chilton <ian@ichilton.co.uk> für die Betreuung des Tipps-Projekt.

• Marc Heerdink <gimli@linuxfromscratch.org> -- LFS Buch Autor.

• Seth W. Klein <sklein@linuxfromscratch.org> -- Erschaffer der LFS FAQ.

• Garrett LeSage <garrett@linuxart.com> -- Erschaffer des ursprünglichen LFS Banners.

• Simon Perreault <nomis80@videotron.ca> -- Betreuer des Tipps Projekt.

• Geert Poels <Geert.Poels@skynet.be> -- Erschaffer des ursprünglichen BLFS Banner; basierend auf dem LFS Banner von Garrett LeSage.

• Frank Skettino <bkenoah@oswd.org> für das ursprüngliche Design der alten Website -- schauen Sie unter http://www.oswd.org/.

• Jesse Tie-Ten-Quee <highos@linuxfromscratch.org> für das Beantworten zahlloser Fragen im IRC und für seine unendliche Geduld.

Dinge die sie angeben sollten

Neben einer kurzen Erklärung des Problems ist es wichtig das sie uns noch folgende Dinge mitteilen:

• Die Version des Buches das sie benutzen (dies ist die Version 5.0),

• die Host-Distribution und Versionsnummer die sie benutzen um LFS zu installieren,

• das Paket oder die Sektion die ihnen Probleme macht,

• die exakte Fehlermeldung oder die genauen Symptome die sie sehen,

• ob sie von den Anleitungen im Buch abgewichen sind.

(Beachten sie: Nur weil sie möglicherweise von den Anweisungen im Buch abgewichen sind, bedeutet das längst nicht das wir ihnen nicht helfen werden. Der Grundsatz von LFS ist es, die Wahl zu haben. Diese Angabe hilft uns lediglich mögliche Ursachen für ihre Problem besser erkennen zu können.)

Probleme mit configure Skripten

Wenn beim durchlaufen der configure Skripte ein Problem auftritt, schauen sie erst einmal in die Datei config.log. Die Datei enthält viele Fehlermeldungen die auf dem Bildschirm sonst nicht angezeigt werden. Geben sie diese Fehlermeldungen mit an wenn sie nach Hilfe fragen.

Kompilierprobleme

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, aber auf der anderen Seite sollte es auch nicht zu wenig sein. Als Beispiel 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

Oft kopieren viele Leute nur den unteren Teil:

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

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

Einen sehr guten Beitrag zu diesem Thema hat Eric S. Raymond geschrieben. sie können ihn lesen unter http://catb.org/~esr/faqs/smart-questions.html. Lesen und befolgen sie bitte seine Tipps in dem Dokument, das erhöht die Chance das sie eine Antwort auf ihre Frage erhalten mit der sie auch etwas anfangen können.

Probleme mit Test-suites

Viele Pakete enthalten eine Test-suite. Abhängig von der Wichtigkeit eines Paketes empfehlen wir ihnen die Test-suite durchlaufen zu lassen. Manchmal erzeugen die Pakete Fehlmeldungen oder unerwartete Ergebnisse. Falls sie solchen Problemen begegnen können sie auf den LFS Wiki Seiten 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.

Bemerkungen zum statischen linken

Fast alle Programme führen neben ihrer eigentlichen Aufgabe noch einige weniger übliche, manchmal sehr triviale Dinge aus. Das beinhaltet das reservieren von Speicher, durchsuchen von Verzeichnissen, lesen und schreiben von Dateien, bearbeiten von Zeichenketten, Mustersuche, Arithmetik und viele andere Dinge. Anstatt Programme zu zwingen das "Rad neu zu erfinden", stellt das GNU System all 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 Code der genutzten Funktionen in die ausführbare Datei eingebettet; das resultiert in einem relativ umfangreichen 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 ist die Programmierschnittstelle des dynamischen Linkers zu benutzen. Schauen sie für weitere Informationen bitte in die Manpage von dlopen.)

Dynamisches linken ist unter Linux der Standard und hat drei grosse Vorteile gegenüber dem statischen linken. Erstens braucht man nur eine Kopie der ausführbaren Bibliothek anstatt viele Kopien in allen möglichen ausführbaren Dateien eingebettet zu haben -- nebenbei spart das auch Speicherplatz auf der Festplatte. Zweitens: Wenn viele Programme die gleichen Bibliotheksfunktionen gleichzeitig nutzen, 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 die eine Bibliothek neu kompilieren anstatt alle Programme neu zu kompilieren die die Bibliothek benutzen.

Wenn der dynamische Linker so viele Vorteile hat, warum linken wir die ersten beiden Pakete in diesem Kapitel dann statisch? 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 wir durch diesen Schritt einen weiteren Punkt unabhängiger vom Host-System werden. Das bedeutet, diese Programme können unabhängig vom Host-System eingesetzt werden. Natürlich könnten wir auch dann noch ein gut funktionierendes LFS System erstellen wenn diese Pakete dynamisch gelinkt werden.

Inhalt von Binutils

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

Installierte Programme: addr2line, ar, as, c++filt, gprof, ld, nm, objcopy, objdump, ranlib, readelf, size, strings und strip

Installierte Bibliotheken: libiberty.a, libbfd.[a,so] und libopcodes.[a,so]

Binutils Installationsabhängigkeiten

Binutils ist abhängig von: Bash, Coreutils, Diffutils, GCC, Gettext, Glibc, Grep, Make, Perl, Sed, Texinfo.

Installieren von Binutils

Es ist wichtig, das Binutils als erstes Paket kompiliert wird, weil Glibc und GCC verschiedene Tests bezüglich Linker und Assembler durchführen und daraufhin erst diverse Features einschalten.

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

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

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

Bereiten sie nun Binutils zum kompilieren vor:

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

Die Bedeutung der configure Parameter:

• --prefix=/tools: Dies teilt dem configure Skript mit, die Installation der Binutils Programme in dem Verzeichnis /tools vorzubereiten.

• --disable-nls: Dies deaktiviert die Internationalisierung (oft auch als i18n abgekürzt). Wir brauchen keine Internationalisierung für unsere statischen Programme und nls verursacht häufig Probleme beim statischen verlinken von Programmen.

Fahren sie mit dem kompilieren des Pakets fort:

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

Die Bedeutung der make Parameter:

• configure-host: Dies erzwingt die sofortige Konfiguration alle Unterverzeichnisse. Eine statisch gebaute Version würde ansonsten fehlschlagen.Wir benutzen diese Option um dieses Problem zu umgehen.

• LDFLAGS="-all-static": Dies teilt dem Linker mit, das alle Binutils Programme statisch gelinkt werden sollen. Genaugenommen wird "-all-static" zuerst an libtool übergeben, welches dann wiederum "-static" an den Linker übergibt.

Und installieren sie das Paket:

make install

Bereiten sie nun den Linker auf das spätere hinzufügen von Glibc vor:

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

Die Bedeutung der make Parameter:

• -C ld clean: Dies weist das make Programm an, alle kompilierten Dateien im Unterverzeichnis ld zu löschen.

• -C ld LDFLAGS="-all-static" LIB_PATH=/tools/lib: Diese Option kompiliert alles im Unterverzeichnis ld erneut. Das angeben der LIB_PATH makefile Variable auf der Kommandozeile überschreibt den Standardwert und zeigt auf das temporäre tools Verzeichnis. Der Wert dieser Variable spezifiziert den Standard Bibliothek Suchpfad für den Linker. Sie werden später in diesem Kapitel sehen wie diese Vorbereitung angewendet wird.

Inhalt von GCC

Das Paket GCC enthält die Gnu Compiler Sammlung, inklusive dem C und C++ Compiler.

Installierte Programme: c++, cc (Link auf gcc), cc1, cc1plus, collect2, cpp, g++, gcc, gccbug, und gcov

Installierte Bibliotheken: libgcc.a, libgcc_eh.a, libgcc_s.so, libstdc++.[a,so] und libsupc++.a

GCC Installationsabhängigkeiten

GCC ist abhängig von: Bash, Binutils, Coreutils, Diffutils, Findutils, Gawk, Gettext, Glibc, Grep, Make, Perl, Sed, Texinfo.

Installieren von GCC

Entpacken sie nur das GCC-core Tar-Archiv; wir werden erstmal keinen C++ Compiler brauchen.

Es ist bekannt, das dieses Paket nicht richtig funktioniert wenn die standard Optimierungseinstellungen (inklusive der -march und -mcpu Optionen) verändert wurden. Deshalb sollten sie event. gesetzte Umgebungsvariablen die die Standard Optimierung überschreiben - zum Beispiel CFLAGS und CXXFLAGS - für den Kompiliervorgang von GCC zurücksetzen oder entsprechend abändern.

Die GCC Dokumentation empfiehlt, GCC nicht im Quellenverzeichnis sondern in einem dazu dedizierten Verzeichnis zu kompilieren:

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

Bereiten sie GCC zum kompilieren vor:

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

Die Bedeutung der configure Optionen:

• --with-local-prefix=/tools: Der Sinn dieses Schalters ist es, /usr/local/include aus dem Suchpfad von gcc zu entfernen. Dies ist nicht absolut zwingend erforderlich, jedoch möchten wir mögliche Einflüsse aus dem Host-System vermeiden, daher ist diese Option hier wichtig.

• --enable-shared: Dieser Schalter scheint hier erstmal nicht besonders klug. Aber durch ihn kompilieren wir sowohl libgcc_s.so.1 und libgcc_eh.a, und die Präsenz von libgcc_eh.a stellt sicher, dass das configure Skript für Glibc (das nächste zu kompilierende Paket) korrekte Ergebnisse erziehlt. Beachten sie, das gcc selbst trotzdem statisch gelinkt wird, das wird durch den Wert -static zu BOOT_LDFLAGS im nächsten Schritt erreicht.

• --enable-languages=c: Diese Option stellt sicher, das nur der C Compiler gebaut wird. Diese Option wird nur benötigt wenn sie das komplette GCC Archiv heruntergeladen und entpackt haben.

Fahren sie mit dem kompilieren des Pakets fort:

make BOOT_LDFLAGS="-static" bootstrap

Die Bedeutung der make Parameter:

• BOOT_LDFLAGS="-static": Dies weist GCC an seine Programme statisch zu verlinken.

• bootstrap: Dieses make target kompiliert GCC nicht einfach nur, sondern kompiliert gleich mehrmals. GCC benutzt die Programme die im ersten Durchlauf erzeugt werden um sich selbst im zweiten Durchlauf erneut zu kompilieren. Dann kompiliert sich GCC noch ein drittes mal. Am Schluss werden die Ergebnisse des zweiten und dritten Kompiliervorgangs verglichen um sicherzustellen das GCC sich selbst problemlos kompilieren konnte. Das bedeutet normalerweise das alles korrekt kompiliert wurde.

Installieren sie das Paket:

make install

Zum Abschluss erstellen wir noch den Symlink /tools/bin/cc. Viele Programme benutzen cc anstelle von gcc, das ist gedacht um Programme generisch zu halten und damit auf verschiedenen Unix System nutzbar zu machen. Nicht jeder hat den GNU C Compiler installiert. Einfach nur cc aufzurufen lässt dem Administrator die Wahl, welchen C Compiler er installieren möchte, solange es einen Symlink auf den echten Compiler gibt:

ln -sf gcc /tools/bin/cc

Inhalt von Linux

Der Linux Kernel ist der Kern eines jeden Linux Systems. Er ist sozusagen der Herzschlag von Linux. Wenn der Computer eingeschaltet wird und ein Linux System startet, dann ist der Kernel das erste Stück Software das gestartet wird. Der Kernel initialisiert die Geräte und Hardware Komponenten: serielle Schnittstellen, parallele Schnittstellen, Soundkarten, Netzwerkkarten, IDE und SCSI Controller und vieles mehr. Zusammenfassend kann man sagen, der Kernel stellt dem System die Hardware zur Verfügung, so das die Software damit laufen kann.

Installierte Dateien: Der Kernel und die Kernel Header

Linux Installationsabhängigkeiten

Linux ist abhängig von: Bash, Binutils, Coreutils, Findutils, GCC, Glibc, Grep, Gzip, Make, Modutils, Perl, Sed.

Installation der Kernel Header

Da einige Pakete die Kernel Header Dateien referenzieren, entpacken wir nun das Kernel Archiv, 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

Das stellt sicher das der Kernel Baum absolut sauber ist. Das Kernel Team empfiehlt, dieses Kommando vor jedem Kernel kompilieren auszuführen. Sie sollten sich nicht darauf verlassen das die Quellen nach dem entpacken sauber sind.

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

make include/linux/version.h

Erstellen sie den Platform-spezifischen Symlink include/asm:

make symlinks

Installieren sie die Plattform-spezifischen Header Dateien:

mkdir /tools/include/asm
cp include/asm/* /tools/include/asm
cp -R include/asm-generic /tools/include

Installieren sie die Multi-Plattform Header Dateien:

cp -R include/linux /tools/include

Es gibt einige wenige Header Dateien die autoconf.h benutzen. Da wir den Kernel jetzt noch nicht konfigurieren, müssen wir die Datei selbst erstellen um mögliche Kompilierfehler zu vermeiden. Erstellen sie die leere autoconf.h Datei:

touch /tools/include/linux/autoconf.h

Inhalt von Glibc

Glibc ist die C Bibliothek, sie stellt Systemaufrufe und grundlegende Funktionen wie open, malloc, printf usw. zur Verfügung. Die C Bibliothek wird von allen dynamisch gelinkten Programmen verwendet.

Installierte Programme: catchsegv, gencat, getconf, getent, glibcbug, iconv, iconvconfig, ldconfig, ldd, lddlibc4, locale, localedef, mtrace, nscd, nscd_nischeck, pcprofiledump, pt_chown, rpcgen, rpcinfo, sln, sprof, tzselect, xtrace, zdump und zic

Installierte Bibliotheken: ld.so, libBrokenLocale.[a,so], libSegFault.so, libanl.[a,so], libbsd-compat.a, libc.[a,so], libc_nonshared.a, libcrypt.[a,so], libdl.[a,so], libg.a, libieee.a, libm.[a,so], libmcheck.a, libmemusage.so, libnsl.a, libnss_compat.so, libnss_dns.so, libnss_files.so, libnss_hesiod.so, libnss_nis.so, libnss_nisplus.so, libpcprofile.so, libpthread.[a,so], libresolv.[a,so], librpcsvc.a, librt.[a,so], libthread_db.so und libutil.[a,so]

Glibc Installationsabhängigkeiten

Glibc ist abhängig von: Bash, Binutils, Coreutils, Diffutils, Gawk, GCC, Gettext, Grep, Make, Perl, Sed, Texinfo.

Glibc Installation

Bevor sie mit der Installation von Glibc beginnen, müssen sie mit cd in das glibc-2.3.2 Verzeichnis wechseln und dort Glibc-linuxthreads entpacken. Entpacken sie Glibc-linuxthreads nicht dort wo sie sonst die Archive entpacken würden, sondern in das Glibc Verzeichnis hinein.

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

Grundsätzlich kann man sagen, wenn sie von dem in diesem Buch beschriebenen Weg zum kompilieren von Glibc abweichen, riskieren sie die Stabilität ihres gesamten LFS Systems.

Auch wenn es nur eine harmlose Meldung ist, die Installationsphase von Glibc wird sich über das fehlen von /tools/etc/ld.so.conf beschweren. Verhindern sie diese störende Meldung:

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

Zusätzlich hat die Glibc ein Problem, wenn sie mit GCC 3.3.1 kompiliert wird. Wenden sie den folgenden Patch an um das Problem zu beheben:

patch -Np1 -i ../glibc-2.3.2-sscanf-1.patch

Die Glibc Dokumentation empfiehlt, nicht im Quellenverzeichnis sondern in einem dafür dedizierten Verzeichnis zu kompilieren:

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

Als nächstes bereiten sie Glibc zum kompilieren vor:

../glibc-2.3.2/configure --prefix=/tools \
    --disable-profile --enable-add-ons \
    --with-headers=/tools/include \
    --with-binutils=/tools/bin \
    --without-gd

Die Bedeutung der configure Optionen:

• --disable-profile: Dies sorgt dafür, das Bibliotheken ohne profiling Informationen erzeugt werden. Lassen sie diese Option weg wenn sie mit den erzeugten Bibliotheken profiling betreiben möchten.

• --enable-add-ons: Dies aktiviert alle Zusätze die zu Glibc installiert wurden, in unserem Fall Linuxthreads.

• --with-binutils=/tools/bin und --with-headers=/tools/include: Genaugenommen werden diese Optionen nicht benötigt. Aber sie stellen sicher, das in Bezug auf die Kernel Header und Binutils Programme nichts schiefgehen kann.

• --without-gd: Diese Option stellt sicher das wir nicht das memusagestat Programm erzeugen, welches seltsamerweise immer gegen die Host-Bibliotheken (libgd, libpng, libz und so weiter) verlinkt wird.

Während dieser Phase bemerken sie möglicherweise die folgende Warnung:

configure: WARNING: *** These auxiliary programs are missing or incompatible versions: msgfmt *** some features will be disabled. *** Check the INSTALL file for required versions.

Das fehlende oder inkompatible Programm msgfmt ist normalerweise harmlos, aber manchmal kann es zu Fehlern beim durchlaufen der Test-suite führen.

Kompilieren sie das Paket:

make

Starten sie die Test-suite:

make check

Die Glibc Test-suite ist sehr stark von einigen Funktionen ihres Host-Systems abhängig, vor allem dem Kernel. Zusätzlich können in diesem Kapitel einige Tests von der Umgebung ihres Host-Systems beeinflusst werden. Diese werden natürlich kein Problem mehr sein, wenn wir später die Glibc Test-suite in der chroot Umgebung in Kapitel 6 ausführen. Grundsätzlich erwarten wir, das die Glibc Test-suite fehlerfrei durchläuft. Nichtsdestotrotz können Fehler unter bestimmten Umständen manchmal nicht vermieden werden. Hier ist eine Liste der uns allgemein bekannten Probleme:

• Der math Test schlägt manchmal fehl wenn sie ein System mit einer älteren Intel oder AMD CPU haben. Optimierungseinstellungen haben hier ebenfalls einen gewissen Einfluss.

• Der gettext Test schlägt manchmal aufgrund von Host-System bedingten Problemen fehl. Die genauen Gründe sind noch nicht ganz geklärt.

• Der atime Test schlägt fehl, wenn die LFS Partition mit der noatime Option gemountet wurde. Auch andere Dateisystemeigenheiten können hier Einfluss haben.

• Der shm Test könnte fehlschlagen wenn das Host-System das devfs Dateisystem laufen hat, aber aufgrund fehlender Kernel Unterstützung kein tmpfs Dateisystem unter /dev/shm gemountet ist.

• Auf alter oder langsamer Hardware können ein paar Tests aufgrund von Timeouts fehlschlagen.

Machen sie sich keine allzugrossen Gedanken wenn ein paar Glibc-Tests in diesem Kapitel fehlschlagen. Die Glibc aus Kapitel 6 ist diejenige die wir endgültig verwenden werden, erst dort ist es wirklich wichtig das die Tests erfolgreich durchlaufen. Aber denken sie daran, selbst in Kapitel 6 können immer noch Fehler auftreten -- beim math Test zum Beispiel. Wenn ein Fehler auftritt, notieren sie ihn, dann fahren sie mit make check fort. Die Test-suite sollte dann dort fortfahren wo sie aufgehört hat. Sie können dieses stoppen und starten umgehen indem sie make -k check aufrufen. Aber wenn sie das tun, stellen sie sicher das sie die Ausgaben mitloggen damit sie später die Logdatei nach den aufgetretenen Fehlern durchsuchen können.

Nun installieren sie das Paket:

make install

Verschiedene Länder und Kulturen haben auch unterschiedliche Konventionen zum kommunizieren. Diese Konventionen reichen von einfachen, wie zum Beispiel dem Format für Datum und Uhrzeit, bis hin zu sehr komplexen Konventionen, wie zum Beispiel der gesprochenen Sprache. Die "internationalisierung" von GNU Programmen funktioniert mithilfe der sogenannten locales. Wir installieren nun die Glibc locales:

make localedata/install-locales

Als Alternative zu dem vorigen Kommando können sie auch nur die locales installieren die sie brauchen oder wollen. Das erreichen sie mit dem localedef Kommando. Informationen dazu finden sie in der Datei INSTALL in den Quellen zu glibc-2.3.2. 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 install-locales target oben installieren einen minimalen Satz an locales die notwendig sind um die nachfolgenden Tests erfolgreich abschliessen 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 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

Inhalt von Tcl

Das Tcl Paket enthält die sog. Tool Command Language.

Installierte Programme: tclsh (Link auf tclsh8.4), tclsh8.4

Installierte Bibliothek: libtcl8.4.so

Tcl Installationsabhängigkeiten

Tcl ist abhängig von: Bash, Binutils, Coreutils, Diffutils, GCC, Glibc, Grep, Make, Sed.

Installieren von Tcl

Dieses und die nächsten beiden Pakete werden nur installiert damit wir die Test-suites 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, das unsere allerwichtigsten Programme und Werkzeuge richtig funktionieren.

Bereiten sie Tcl zum kompilieren vor:

cd unix
./configure --prefix=/tools

Kompilieren sie das Paket:

make

Dieses Paket enthält eine Test-suite um zu überprüfen das alles korrekt kompiliert wurde. Es ist jedoch bekannt, das die Tcl Test-suite unter bestimmten Bedingungen fehlschlägt. Daher sind Fehler in der Test-suite nicht überraschend, wir betrachten diese Fehler nicht als kritisch. Wenn sie die Test-suite dennoch ausführen möchten, erledigt das folgende Kommando dies für sie:

TZ=UTC make test

Die bedeutung des make Parameters:

• TZ=UTC: Setzt die Zeitzone für die dauer des Test-suite Durchlauf auf Coordinated Universal Time (UTC), auch als Greenwhich Mean Time (GMT) bekannt. Dadurch werden zeitbezogene Tests korrekt ausgewertet. Mehr Informationen zu der TZ Umgebungsvariable finden sie Später in Kapitel 7.

Manchmal erzeugt eine Test-suite falschen Alarm. Schlagen sie im LFS Wiki unter http://wiki.linuxfromscratch.org/ nach um zu überprüfen das mögliche Fehler normal sind. Das gilt für sämtliche Test-suiten im gesamten Buch.

Installieren sie das Paket:

make install

Erstellen sie einen nötigen symbolischen Link:

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

Inhalt von Expect

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

Installierte Programme: expect

Installierte Bibliotheken: libexpect5.39.a

Expect Installationsabhängigkeiten

Expect ist abhängig von: Bash, Binutils, Coreutils, Diffutils, GCC, Glibc, Grep, Make, Sed, Tcl.

Installieren von Expect

Wenden sie erst einen Patch an:

patch -Np1 -i ../expect-5.39.0-spawn.patch

Dies behebt einen Fehler in Expect der ansonsten Fehlalarme beim durchlaufen der GCC Test-suite verursachen könnte.

Bereiten sie nun Expect zum kompilieren vor:

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

Die Bedeutung der configure Optionen:

• --with-tcl=/tools/lib: So stellen wir sicher das das configure Skript die Tcl-Installation in unserem temporären Verzeichnis findet. Es sollte keine möglicherweise auf dem Host-System installierte Version gefunden werden.

• --with-x=no: Dies teilt dem configure Skript mit das es nicht nach Tk (der grafischen Oberfläche zu Tcl) oder den X-Window Bibliotheken suchen soll, beide existieren möglicherweise auf dem Host-System.

Kompilieren sie das Paket:

make

Dieses Paket hat eine Test-suite die sicherstellt das das Paket korrekt gebaut wurde. Es ist jedoch bekannt das diese Test-suite hier im Kapitel 5 Probleme macht die noch nicht ganz nachvollzogen wurden. Es ist daher nicht überraschend, wenn die Test-suite Fehler meldet, diese werden jedoch nicht als kritisch betrachtet. Sollten sie sich entscheiden, die Test-suite dennoch laufen zu lassen, dann benutzen sie dieses Kommando:

make test

Und installieren sie:

make SCRIPTS="" install

Die Bedeutung des make Parameters:

• SCRIPTS="": Dies verhindert die Installation der mitgelieferten Expect Skripte, wir brauchen sie hier nicht.

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

Inhalt von DejaGnu

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

Installiertes Programm: runtest

DejaGnu Installationsabhängigkeiten

Dejagnu ist abhängig von: Bash, Binutils, Coreutils, Diffutils, GCC, Glibc, Grep, Make, Sed.

Installieren von DejaGnu

Bereiten sie DejaGnu zum kompilieren vor:

./configure --prefix=/tools

Kompilieren und installieren sie das Paket:

make install

Neuinstallation von GCC

Die Hilfmittel zum testen von GCC und Binutils sind nun installiert (Tcl, Expect und DejaGnu). Wir können GCC und Binutils nun erneut installieren, sie gegen die neue Glibc verlinken und testen. Eine Sache die es noch zu beachten gibt: Die Test-suites sind stark von funktionierenden Pseudo-Terminals (PTYs) abhängig. Diese werden von dem Host-System bereitgestellt. Heutzutage werden PTYs meist über das devpts Dateisystem implementiert. Ob ihr Host-System korrekt eingerichtet ist können sie mit einem einfachen Test feststellen:

expect -c "spawn ls"

Wenn sie diese Meldung erhalten:

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

ist ihr Host-System nicht korrekt für PTYs eingerichtet. Solange sie dieses Problem nicht behoben haben brauchen sie die Test-suites 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 LSF Wiki unter http://wiki.linuxfromscratch.org/.

Entpacken sie alle drei GCC Tar-Archive (-core, -g++ und -testsuite) in ein und demselben Arbeitsverzeichnis. Die Archive entpacken sich in ein einziges gcc-3.3.1/ Unterverzeichnis.

Als erstes korrigieren sie ein Problem und machen eine wichtige Anpassung:

patch -Np1 -i ../gcc-3.3.1-no_fixincludes-2.patch
patch -Np1 -i ../gcc-3.3.1-specs-2.patch

Der este Patch schaltet das GCC "fixincludes" Skript ab. Wir haben das vorher schonmal kurz erwähnt, hier wollen wir eine tiefere Erklärung dazu geben. Unter normalen Umständen durchsucht das GCC fixincludes Skript ihr System nach Header Dateien die repariert werden müssen. Es könnte allerdings der Meinung sein das einige Header Dateien auf ihrem Host-System repariert werden müssen, repariert diese und kopiert sie in das private GCC Include Verzeichnis. Später dann in Kapitel 6, nachdem wir die neuere Glibc installiert haben, würde dieses private Include Verzeichnis vor den System Include Verzeichnissesn durchsucht werden. GCC würde dann die reparierten Include Dateien von ihrem Host-System finden, und diese passen dann nicht zu der Glibc Version die wir für das LFS System verwendet haben.

Der letzte Patch ändert den GCC standard Pfad des dynamischen Linkers (üblicherweise ld-linux.so.2). Ausserdem entfernt er /usr/include aus dem GCC Include Suchpfad. Durch das jetzige Patchen anstelle des nachträglichen anpassens der specs Datei stellen wir sicher das unser neuer dynamischer Linker während dem Bau von GCC verwendet wird. Das bedeutet, alle endgültigen (und auch temporären) Binärdateien während dem Kompilierdurchlauf werden gegen die neue Glibc gelinkt.

Erstellen sie erneut ein dediziertes Verzeichnis zum kompilieren:

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

Bevor sie mit dem kompilieren von GCC beginnen, denken sie daran alle Umgebungsvariablen zurückzusetzen die die Standard Optimierungen überschreiben würden.

Bereiten sie nun GCC zum kompilieren vor:

../gcc-3.3.1/configure --prefix=/tools \
    --with-local-prefix=/tools \
    --enable-clocale=gnu --enable-shared \
    --enable-threads=posix --enable-__cxa_atexit \
    --enable-languages=c,c++

Die Bedeutung der neuen configure Optionen:

• --enable-threads=posix: Das schaltet die Behandlung von C++ exceptions für Threads ein.

• --enable-__cxa_atexit: Diese Option erlaubt die Benutzung von __cxa_atexit anstelle von atexit um C++ Destruktoren für lokale statics und globale Objekte zu registrieren. Ausserdem ist die Option für eine vollständig Standard-konforme Behandlung von Destruktoren erforderlich. Das beeinflusst auch die C++ ABI; das Ergebnis sind C++ shared libraries und C++ Programme die interoperabel mit anderen Linux Distributionen sind.

• --enable-clocale=gnu: Diese Option stellt sicher, das unter allen Umständen das korrekte locale Modell für die C++ Bibliotheken ausgewählt wird. Falls das configure Skript de_DE locales findet, wird es das korrekte Modell von gnu wählen. Falls aber de_DE nicht installiert ist, besteht das Risiko aufgrund des fälschlicherweise ausgewählten Modells generic ABI-inkompatible C++ Bibliotheken zu erzeugen.

• --enable-languages=c,c++: Diese Option wird benötigt damit sowohl C, als auch C++ Compiler erzeugt werden.

Kompilieren sie das Paket:

make

Diesmal müssen sie nicht das bootstrap target verwenden, weil wir bereits einen Compiler benutzen der aus exakt den gleichen Quellen gebaut wurde.

Testen sie die Ergebnisse:

make -k check

Der Schalter -k lässt die Test-suite bis zum Ende durchlaufen, auch wenn Fehler auftreten sollten. Die GCC Test-suite ist sehr umfangreich und es ist beinahe sicher das Fehler auftreten. Um eine Zusammenfassung der Test Ergebnisse zu erhalten benutzen sie dieses Kommando:

../gcc-3.3.1/contrib/test_summary | more

Sie können ihre Ergebnisse mit denen auf der gcc-testresults Mailingliste veröffentlichten vergleichen die eine ähnliche System-Konfiguration wie sie haben. Ein Beispiel wie GCC-3.3.1 auf i686-pc-linux-gnu aussehen sollte finden sie unter http://gcc.gnu.org/ml/gcc-testresults/2003-08/msg01612.html.

Beachten sie, das das Ergebnis folgendes enthält:

* 1 XPASS (unexpected pass) for g++
* 1 FAIL (unexpected failure) for g++
* 2 FAIL for gcc
* 26 XPASS's for libstdc++

Der unerwartet erfolgreiche Durchlauf für g++ ist weil wir --enable-__cxa_atexit benutzt haben. Offensichtlich unterstützen nicht alle von GCC unterstützten Plattformen "__cxa_atexit" in ihren C Bibliotheken, daher wird das erfolgreiche durchlaufen dieses Tests als unerwartet betrachtet.

Die 26 unerwartet erfolgreichen Durchläufe für libstdc++ sind begründet durch die Option --enable-clocale=gnu, welches die korrekte Wahl auf Glibc basierten Systemen Version 2.2.5 oder höher ist. Die zugrundeliegende locale Unterstützung in der GNU C Bibliothek ist besser als das ansonsten gewählte Modell "generic" (welches anwendbar wäre, wenn sie zum Beispiel Newlibc, Sun-libc oder eine sonstige libc verwenden würden). Die libstdc++ Test-suite erwartet anscheinend das "generic" Modell, daher wird nicht erwartet das dieses Tests erfolgreich durchlaufen.

Unerwartete Fehler lassen sich oftmals gar nicht vermeiden. Die GCC Entwickler kennen diese üblicherweise bereits, aber hatten noch keine Zeit diese Fehler zu beheben. Kurz gesagt, solange ihre Test Ergebnisse nicht grob von denen unter der obigen URL abweichen, ist es in Ordnung einfach fortzufahren.

Schlussendlich installieren sie das Paket:

make install

Neuinstallation von Binutils

Erstellen sie erneut ein separates Verzeichnis zum kompilieren:

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

Bereiten sie nun Binutils zum kompilieren vor:

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

Die Bedeutung der neuen configure Option:

• --with-lib-path=/tools/lib: Dies teilt dem configure Skript mit, den Standard Bibliothek-Suchpfad vorzugeben. Wir möchten im Standard Bibliothek-Suchpfad keine Verzeichnisse unseres Host Systems haben, daher geben wir den gewünschten Pfad vor.

Bevor sie beginnen, Binutils zu kompilieren, denken sie daran alle Umgebungsvariablen zu entfernen, die die Standard Optimierungen übergehen würden.

Kompilieren sie das Paket:

make 

Testen sie das Ergebnis (es sollten keine unerwarteten Fehler auftreten, erwartete Fehler sind in Ordnung):

make check

Leider gibt es hier keine einfache Möglichkeit die Testergebnisse zusammenfassend anzuzeigen wie im vorigen GCC Paket. Nichtsdestotrotz, wenn ein Fehler auftritt sollte er leicht zu erkennen sein. Die Ausgabe zeigt dann soetwas wie:

make[1]: *** [check-binutils] Error 2

Und installieren sie das Paket:

make install

Nun bereiten sie Binutils auf das erneute umkonfigurieren der toolchain im nächsten Kapitel vor:

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

Inhalt von Gawk

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

Installierte Programme: awk (Link auf gawk), gawk, gawk-3.1.3, grcat, igawk, pgawk, pgawk-3.1.3 und pwcat

Gawk Installationsabhängigkeiten

Gawk ist abhängig von: Bash, Binutils, Coreutils, Diffutils, GCC, Gettext, Glibc, Grep, Make, Sed.

Installieren von Gawk

Bereiten sie Gawk zum kompilieren vor:

./configure --prefix=/tools

Kompilieren sie das Paket:

make

Dieses Paket enthält eine Test-suite die sicherstellt das alles korrekt kompiliert wurde. Wenn sie die Test-suite ausführen möchten erledigt dies das folgende Kommando:

make check

Und installieren sie es:

make install

Inhalt von Coreutils

Das Paket Coreutils enthält eine große Anzahl von Shell Werkzeugen.

Installierte Programme: basename, cat, chgrp, chmod, chown, chroot, cksum, comm, cp, csplit, cut, date, dd, df, dir, dircolors, dirname, du, echo, env, expand, expr, factor, false, fmt, fold, groups, head, hostid, hostname, id, install, join, kill, link, ln, logname, ls, md5sum, mkdir, mkfifo, mknod, mv, nice, nl, nohup, od, paste, pathchk, pinky, pr, printenv, printf, ptx, pwd, readlink, rm, rmdir, seq, sha1sum, shred, sleep, sort, split, stat, stty, su, sum, sync, tac, tail, tee, test, touch, tr, true, tsort, tty, uname, unexpand, uniq, unlink, uptime, users, vdir, wc, who, whoami und yes

Coreutils Installationsabhängigkeiten

Coreutils ist abhängig von: Bash, Binutils, Coreutils, Diffutils, GCC, Gettext, Glibc, Grep, Make, Perl, Sed.

Installieren von Coreutils

Bereiten sie Coreutils zum kompilieren vor:

./configure --prefix=/tools

Kompilieren sie das Paket:

make

Dieses Paket enthält eine Test-suite um sicherzustellen das alles korrekt gebaut wurde. Sie sollten die Test-suite ausführen; benutzen sie dazu das folgende Kommando:

make RUN_EXPENSIVE_TESTS=yes check

Die Bedeutung der make Parameter:

• RUN_EXPENSIVE_TESTS=yes: Dies teilt der Test-suite mit, noch zusätzliche Tests zu durchlaufen die auf einigen Plattformen sehr zeitintensiv sein können. Normalerweise ist das unter Linux aber kein Problem.

Und installieren sie das Paket:

make install

Inhalt von Bzip2

Bzip2 ein Block-sortierendes Kompressionsprogramm und erreicht üblicherweise bessere Kompressionsraten als das herkömmliche gzip.

Installierte Programme: bunzip2 (Link auf bzip2), bzcat (Link auf bzip2), bzcmp, bzdiff, bzegrep, bzfgrep, bzgrep, bzip2, bzip2recover, bzless und bzmore

Installierte Bibliotheken: libbz2.a, libbz2.so (Link auf libbz2.so.1.0), libbz2.so.1.0 (Link auf libbz2.so.1.0.2) und libbz2.so.1.0.2

Bzip2 Installationsabhängigkeiten

Bzip2 ist abhängig von: Bash, Binutils, Coreutils, Diffutils, GCC, Glibc, Make.

Installieren von Bzip2

Das Paket Bzip2 enthält kein configure Skript. Kompilieren und installieren sie es einfach mit:

make PREFIX=/tools install

Inhalt von Gzip

Gzip enthält Programme für die Dateikompression und -dekompression mit Hilfe des Lempel-Ziv Algorythmus (LZ77).

Installierte Programme: gunzip (Link auf gzip), gzexe, gzip, uncompress (Link auf gunzip), zcat (Link auf gzip), zcmp, zdiff, zegrep, zfgrep, zforce, zgrep, zless, zmore und znew

Gzip Installationsabhängigkeiten

Gzip ist abhängig von: Bash, Binutils, Coreutils, Diffutils, GCC, Glibc, Grep, Make, Sed.

Installation von Gzip

Bereiten sie Gzip zum kompilieren vor:

./configure --prefix=/tools

Kompilieren sie das Paket:

make

Und installieren sie es:

make install

Inhalt von Diffutils

Die Programme dieses Pakets können die Unterschiede zwischen zwei Dateien oder Verzeichnissen anzeigen. Die häufigste Anwendung ist das erstellen von Software-Patches.

Installierte Programme: cmp, diff, diff3 und sdiff

Diffutils Installationsabhängigkeiten

Diffutils ist abhängig von: Bash, Binutils, Coreutils, Diffutils, GCC, Gettext, Glibc, Grep, Make, Sed.

Installieren von Diffutils

Bereiten sie Diffutils zum kompilieren vor:

./configure --prefix=/tools

Kompilieren sie das Paket:

make

Und installieren sie es:

make install

Inhalt von Findutils

Das Findutils Paket enthält Programme zum auffinden von Dateien, entweder on-the-fly (indem ein Verzeichnisbaum live durchsucht wird) oder durch Suche in einer Datenbank.

Installierte Programme: bigram, code, find, frcode, locate, updatedb und xargs

Findutils Installationsabhängigkeiten

Findutils ist abhängig von: Bash, Binutils, Coreutils, Diffutils, GCC, Gettext, Glibc, Grep, Make, Sed.

Installieren von Findutils

Bereiten sie Findutils zum kompilieren vor:

./configure --prefix=/tools

Kompilieren sie das Paket:

make 

Dieses Paket hat eine Test-suite die sicherstellt das alles korrekt kompiliert wurde. Falls sie diese durchlaufen wollen, erledigt dies das folgende Kommando:

make check

Und installieren sie das Paket:

make install

Inhalt von Make

Make erkennt automatisch, welche Teile eines grossen Programmes erneut kompiliert werden müssen und welche Kommandos dazu nötig sind.

Installiertes Programm: make

Make Installationsabhängigkeiten

Make ist abhängig von: Bash, Binutils, Coreutils, Diffutils, GCC, Gettext, Glibc, Grep, Sed.

Installation von Make

Bereiten sie Make zum kompilieren vor:

./configure --prefix=/tools

Kompilieren sie das Programm:

make 

Dieses Paket enthält eine Test-suite zum überprüfen ob alles korrekt kompiliert wurde. Sollten sie sich entscheiden die Test-suite durchlaufen zu lassen, erledigt dies das folgende Kommando für sie:

make check

Nun installieren sie Make und die dazugehörige Dokumentation:

make install

Inhalt von Grep

Grep zeigt alle Zeilen einer Datei an die auf ein bestimmtes Muster passen.

Installierte Programme: egrep (Link auf grep), fgrep (Link auf grep) und grep

Grep Installationsabhängigkeiten

Grep ist abhängig von: Bash, Binutils, Coreutils, Diffutils, GCC, Gettext, Glibc, Make, Sed, Texinfo.

Installation von Grep

Bereiten sie Grep zum kompilieren vor:

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

Die Bedeutung der configure Optionen:

• --disable-perl-regexp: Dies stellt sicher das grep nicht gegen die PCRE Bibliothek verlinkt wird die eventuell auf dem Host-System installiert ist, aber dann später in der chroot Umgebung nicht mehr verfügbar wäre.

• --with-included-regex: Dies stellt sicher das Grep seinen eingebauten Code für Reguläre Ausdrücke benutzt. Ohne diesen würde es den Code von Glibc benutzen, der aber bekannt dafür ist, ein wenig Fehlerhaft zu sein.

Kompilieren sie die Programme:

make 

Dieses Paket hat eine Test-suite die überprüft ob alles korrekt kompiliert wurde. Wenn sie diese laufen lassen wollen führen sie das folgende Kommando aus:

make check

Dann installieren sie sie und die dazugehörige Dokumentation:

make install

Inhalt von Sed

Sed ist ein Stream Editor. Mit einem Stream Editor kann man einfache Textmanipulationen an einem Eingabestream vornehmen (z. B. einer Datei oder einer Pipe).

Installiertes Programm: sed

Sed Installationsabhängigkeiten

Sed ist abhängig von: Bash, Binutils, Coreutils, Diffutils, GCC, Gettext, Glibc, Grep, Make, Texinfo.

Installieren von Sed

Bereiten sie Sed zum kompilieren vor:

./configure --prefix=/tools

Kompilieren sie das Programm:

make 

Dieses Paket enthält eine Test-suite um zu überprüfen ob alles korrekt kompiliert wurde. Wenn sie sie ausführen möchten, erledigt das folgende Kommando dies für sie:

make check

Dann installieren sie Programm und Dokumentation:

make install

Inhalt von Gettext

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

Installierte Programme: autopoint, config.charset, config.rpath, gettext, gettextize, hostname, msgattrib, msgcat, msgcmp, msgcomm, msgconv, msgen, msgexec, msgfilter, msgfmt, msggrep, msginit, msgmerge, msgunfmt, msguniq, ngettext, project-id, team-address, trigger, urlget, user-email und xgettext

Installierte Bibliotheken: libasprintf[a,so], libgettextlib[a,so], libgettextpo[a,so] und libgettextsrc[a,so]

Gettext Installationsabhängigkeiten

Gettext ist abhängig von: Bash, Binutils, Bison, Coreutils, Diffutils, Gawk, GCC, Glibc, Grep, Make, Sed.

Installieren von Gettext

Bereiten sie Gettext zum kompilieren vor:

./configure --prefix=/tools

Kompilieren sie die Programme:

make

Dieses Paket enthält eine Test-suite zum überprüfen der kompilierten Programme. Es ist jedoch bekannt das die Gettext Test-suite hier in Kapitel 5 unter verschiedenen Bedingungen fehlschlägt -- zum Beispiel wenn sie einen Java Compiler auf dem Host-System findet. Die Gettext Test-suite braucht sehr viel Zeit und ist nicht als kritisch einzustufen. Deshalb empfehlen wir, diesen Schritt zu überspringen. Sollten sie dennoch die Test-suite laufen lassen wollen, erledigt dieses Kommando das für sie:

make check

Und installieren sie das Paket:

make install

Inhalt von Ncurses

Ncurses enthält Bibliotheken zur Verwendung von Zeichen und Terminals, inklusive Schaltflächen und Menüs.

Installierte Programme: captoinfo (Link auf tic), clear, infocmp, infotocap (Link auf tic), reset (Link auf tset), tack, tic, toe, tput und tset

Installierte Bibliotheken: libcurses.[a,so] (Link auf libncurses.[a,so]), libform.[a,so], libmenu.[a,so], libncurses++.a, libncurses.[a,so], libpanel.[a,so]

Ncurses Installationsabhängigkeiten

Ncurses ist abhängig von: Bash, Binutils, Coreutils, Diffutils, Gawk, GCC, Glibc, Grep, Make, Sed.

Installation von Ncurses

Beheben sie zuerst zwei kleine Fehler:

patch -Np1 -i ../ncurses-5.3-etip-2.patch
patch -Np1 -i ../ncurses-5.3-vsscanf.patch

Der erste Patch korrigiert die Header Datei etip.h, und der zweite Patch unterbindet einige Compiler Warnungen bezüglich der Benutzung veralteter Header.

Bereiten sie Ncurses zum kompilieren vor:

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

Die bedeutung der configure Optionen:

• --without-ada: Das bewirkt, das Ncurses ohne Ada Bindungen erstellt wird, selbst wenn auf dem Host-System ein Ada Compiler vorhanden ist. Das ist erforderlich weil später in der chroot Umgebung Ada nicht mehr verfügbar sein wird.

• --enable-overwrite: Dadurch werden die Ncurses Header Dateien in /tools/include anstelle von /tools/include/ncurses installiert. Das stellt sicher das andere Pakete die Ncurses Header Dateien problemlos finden können.

Kompilieren sie die Programme und Bibliotheken:

make 

Und dann installieren sie sie und ihre Dokumentation:

make install

Inhalt von Patch

Patch manipuliert Dateien auf Basis einer Patch-Datei. Eine Patch-Datei ist üblicherweise eine Liste mit Änderungsanweisungen die mit Hilfe des Programms diff erzeugt wurde.

Installiertes Programm: patch

Patch Installationsabhängigkeiten

Patch ist abhängig von: Bash, Binutils, Coreutils, Diffutils, GCC, Glibc, Grep, Make, Sed.

Installieren von Patch

Bereiten sie Patch zum kompilieren vor:

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

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

Kompilieren sie das Programm:

make 

Und dann installieren sie es mit der dazugehörigen Dokumentation:

make install

Inhalt von Tar

Tar ist ein Programm zum speichern und extrahieren von Dateien aus sog. Tar-Archiven.

Installierte Programme: rmt und tar

Tar Installationsabhängigkeiten

Tar ist abhängig von: Bash, Binutils, Coreutils, Diffutils, GCC, Gettext, Glibc, Grep, Make, Sed.

Installieren von Tar

Bereiten sie Tar zum kompilieren vor:

./configure --prefix=/tools

Komipilieren sie die Programme:

make 

Dieses Paket beinhaltet eine Test-suite um zu überprüfen das alles korrekt kompiliert wurde. Wenn sie die Suite durchlaufen lassen möchten, erledigt dies das folgende Kommando:

make check

Dann installieren sie die Programme und ihre Dokumentation:

make install

Inhalt von Texinfo

Texinfo enthält Programme zum lesen, schreiben und konvertieren von Info Dokumenten (System Dokumentation).

Installierte Programme: info, infokey, install-info, makeinfo, texi2dvi und texindex

Texinfo Installationsabhängigkeiten

Texinfo ist abhängig von: Bash, Binutils, Coreutils, Diffutils, GCC, Gettext, Glibc, Grep, Make, Ncurses, Sed.

Installieren von Texinfo

Bereiten sie Texinfo zum kompilieren vor:

./configure --prefix=/tools

Kompilieren sie die Programme:

make 

Dieses Paket enthält eine Test-suite zum überprüfen ob alles korrekt kompiliert wurde. Wenn sie die Test-suite ausführen möchten, führen sie folgendes Kommando aus:

make check

Dann installieren sie sie und die Dokumentation:

make install

Inhalt von Bash

Bash ist die "Bourne Again SHell", ein auf Unix Systemen weit verbreiteter Befehlsinterpreter. Die Bash liest Befehle von der Standard Eingabe (der Tastatur). Ein Anwender gibt etwas ein und die Bash wertet die Eingabe aus. Je nach Eingabe reagiert die Bash entsprechend und führt zum Beispiel ein Programm aus.

Installierte Programme: bash, sh (Link auf bash) und bashbug

Bash Installationsabhängigkeiten

Bash ist abhängig von: Binutils, Coreutils, Diffutils, Gawk, GCC, Glibc, Grep, Make, Ncurses, Sed.

Installieren von Bash

Die Bash enthält einige bekannte Fehler. Beheben sie diese mit dem folgenden Patch:

patch -Np1 -i ../bash-2.05b-2.patch

Bereiten sie Bash nun zum kompilieren vor:

./configure --prefix=/tools

Kompilieren sie das Programm:

make

Dieses Paket enthält eine Test-suite die mit einigen Prüfungen sicherstellt, das alles korrekt gebaut wurde. Sollten sie diese durchlaufen lassen wollen führen sie dieses Kommando aus:

make tests

Dann installieren sie das Programm und die Dokumentation:

make install

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

ln -s bash /tools/bin/sh

Inhalt von Util-linux

Util-linux enthält verschiedene Werkzeuge. Einige der etwas bekannteren Programme werden z. B. zum mounten, entmounten, formatieren, partitionieren und verwalten von Festplatten, öffnen von tty Ports und zum auslesen von Kernel Meldungen genutzt.

Installierte Programme: agetty, arch, blockdev, cal, cfdisk, chkdupexe, col, colcrt, colrm, column, ctrlaltdel, cytune, ddate, dmesg, elvtune, fdformat, fdisk, fsck.cramfs, fsck.minix, getopt, hexdump, hwclock, ipcrm, ipcs, isosize, kill, line, logger, look, losetup, mcookie, mkfs, mkfs.bfs, mkfs.cramfs, mkfs.minix, mkswap, more, mount, namei, parse.bash, parse.tcsh, pg, pivot_root, ramsize (Link auf rdev), raw, rdev, readprofile, rename, renice, rev, rootflags (Link auf rdev), script, setfdprm, setsid, setterm, sfdisk, swapoff (Link auf swapon), swapon, test.bash, test.tcsh, tunelp, ul, umount, vidmode (Link auf rdev), whereis und write

Util-linux Installationsabhängigkeiten

Util-linux ist abhängig von: Bash, Binutils, Coreutils, Diffutils, GCC, Gettext, Glibc, Grep, Make, Ncurses, Sed, Zlib.

Installieren von Util-linux

Util-linux verwendet nicht die gerade frisch installierten Header und Bibliotheken im /tools Verzeichnis. Das korrigieren wir durch anpassen des configure Skriptes:

cp configure configure.backup
sed "s@/usr/include@/tools/include@g" configure.backup > configure 

Bereiten sie Util-linux zum kompilieren vor:

./configure

Kompilieren sie einige Subroutinen:

make -C lib

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

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

Nun kopieren wir diese Programme in unser temporäres tools Verzeichnis:

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

Inhalt von Perl

Das Perl Paket enthält die Skriptsprache Perl (Practical Extraction and Report Language). Perl kombiniert einige der besten Merkmale von C, sed, awk und sh in einer einzigen, mächtigen Skriptsprache.

Installierte Programme: a2p, c2ph, dprofpp, enc2xs, find2perl, h2ph, h2xs, libnetcfg, perl, perl5.8.0 (Link auf perl), perlbug, perlcc, perldoc, perlivp, piconv, pl2pm, pod2html, pod2latex, pod2man, pod2text, pod2usage, podchecker, podselect, psed (Link auf s2p), pstruct (Link auf c2ph), s2p, splain und xsubpp

Installierte Bibliotheken: (zu viele um sie einzeln aufzulisten)

Perl Installationsabhängigkeiten

Perl ist abhängig von: Bash, Binutils, Coreutils, Diffutils, Gawk, GCC, Glibc, Grep, Make, Sed.

Installieren von Perl

Zuerst müssen sie ein paar festeingestellte Pfade zur C Bibliothek anpassen:

patch -Np1 -i ../perl-5.8.0-libc-3.patch

Und dann stellen sie sicher das ein paar statische Erweiterungen erzeugt werden:

chmod u+w hints/linux.sh
echo 'static_ext="IO re Fcntl"' >> hints/linux.sh

Bereiten sie Perl zum kompilieren vor:

./configure.gnu --prefix=/tools

Kompilieren sie nur ein paar benötigte Programmteile:

make perl utilities

Dann kopieren sie die Werkzeuge und ihre Bibliotheken an die richtige Stelle:

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

Anmerkung zur FHS Konformität

Unser Verzeichnisbaum basiert auf dem FHS Standard (verfügbar unter http://www.pathname.com/fhs/). Zusätzlich zu den oben erstellten Verzeichnissen 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 Verzeichnisse erstellt die wir für nötig halten.

Inhalt von MAKEDEV

Das Skript MAKEDEV erstellt statische Gerätedateien. Diese liegen normalerweise im /dev Verzeichnis. Detaillierte Informationen über die Gerätedateien finden sie in der Datei Documentation/devices.txt in den Linux Kernel Quellen.

Installiertes Skript: MAKEDEV

MAKEDEV Installationsabhängigkeiten

Make ist abhängig von: Bash, Coreutils.

Erstellen von Gerätedateien

Beim entpacken von MAKEDEV-1.7.bz2 wird keine neues Verzeichnis erstellt in welches sie cd'en könnten, da es nur ein Shell Skript enthält.

Installieren sie das MAKEDEV Skript:

bzcat MAKEDEV-1.7.bz2 > /dev/MAKEDEV
chmod 754 /dev/MAKEDEV

Führen sie das Skript aus um die Gerätedateien zu erzeugen:

cd /dev
./MAKEDEV -v generic-nopty

Die Bedeutung der Argumente:

• -v: Dadurch wird das Skript "gesprächiger", der sogenannte verbose Modus.

• generic-nopty: Das weist MAKEDEV an, die übliche Auswahl der gängigen Spezialdateien zu erstellen, ausser der ptyXX und ttyXX Dateien. Wir brauchen diese Dateien nicht, weil wir Unix98 PTYs über das devpts Dateisystem benutzen werden.

Falls sich herausstellen sollte, das ihnen z. B. die Spezialdatei zzz fehlt, führen sie einfach ./MAKEDEV -v zzz aus. Alternativ können sie auch das mknod Programm dazu benutzen. Bitte lesen sie seine Manpage wenn sie dazu mehr Informationen benötigen.

Falls sie desweiteren im Kapitel "Einhängen des proc- und devpts Dateisystem" Schwierigkeiten beim mounten hatten, ist jetzt eine gute Gelegenheit die Alternativen zu versuchen. Wenn ihr Kernel das devfs Dateisystem unterstützt führen sie folgendes Kommando aus:

mount -t devfs devfs /dev

Das mountet das devfs Dateisystem über die statische Struktur des /etc Verzeichnisses. Das ist kein Problem, denn die erstellen Gerätedateien werden dadurch nicht gelöscht, das devfs Dateisystem versteckt sie lediglich.

Wenn auch das nicht funktioniert, bleibt ihnen nur die Möglichkeit, mittels dem MAKEDEV Skript auch die ptyXX und ttyXX Dateien zu ereugen, die natürlich sonst nicht benötigt werden würden. Stellen sie erst sicher das sie sich noch im /dev Verzeichnis befinden und führen sie dann ./MAKEDEV -v pty aus. Das unschöne daran ist, das wir zusätzliche 512 spezielle Gerätetreiber Dateien erzeugen, die dann später nach dem fertigstellen des LFS Systems nicht mehr benötigt werden.

Inhalt von Linux

Der Linux Kernel ist der Kern eines jeden Linux Systems. Er ist sozusagen der Herzschlag von Linux. Wenn der Computer eingeschaltet wird und ein Linux System startet, dann ist der Kernel das erste Stück Software das gestartet wird. Der Kernel initialisiert die Geräte und Hardware Komponenten: serielle Schnittstellen, parallele Schnittstellen, Soundkarten, Netzwerkkarten, IDE und SCSI Controller und vieles mehr. Zusammenfassend kann man sagen, der Kernel stellt dem System die Hardware zur Verfügung, so das die Software damit laufen kann.

Installierte Dateien: Der Kernel und die Kernel Header

Linux Installationsabhängigkeiten

Linux ist abhängig von: Bash, Binutils, Coreutils, Findutils, GCC, Glibc, Grep, Gzip, Make, Modutils, Perl, Sed.

Installation der Kernel Header

Wir werden jetzt noch keinen neuen Kernel kompilieren -- das erledigen wir, wenn wir die Installation aller Pakete abgeschlossen haben. Da aber einige Pakete die Kernel Header benötigen entpacken wir nun das Kernel Archiv, bereiten es vor und kopieren die Header Dateien damit sie von diesen Paketen gefunden werden.

Beachten sie bitte das die Dateien im Kernel Quellverzeichnis nicht root gehören. Immer wenn sie ein Paket als root Benutzer entpacken (so wie wir es hier im chroot tun), erhalten die entpackten Dateien die Benutzer- und Gruppen ID desjenigen der das Archiv erstellt hat. Das ist üblicherweise für normale Pakete kein Problem weil sie das Quellverzeichnis nach der Installation löschen. Aber die Linux Quellen liegen normalerweise sehr lange auf ihrem Computer, daher ist die Chance gross, das ein zukünftiger Benutzer auf ihrem System die Benutzer ID erhält die ihre Kernel Quellen nun haben, und damit wäre er der Besitzer dieser Dateien und hat dann auch Schreibrechte darauf.

Unter diesem Aspekt möchten sie vielleicht chown -R 0:0 auf das linux-2.4.22 Verzeichnis anwenden damit alle Dateien dem root Benutzer gehören.

Bereiten sie die Installation der Header vor:

make mrproper

Dadurch wird sichergestellt, das die Kernelquellen absolut sauber sind. Das Kernel Team empfiehlt, dieses Kommando vor jedem Neubau des Kernels auszuführen. Sie sollten sich nicht darauf verlassen, das die Quellen nach dem entpacken sauber sind.

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

make include/linux/version.h

Erstellen sie den Plattform-spezifischen symbolischen Link include/asm:

make symlinks

Installieren sie die Plattform-spezifischen Header Dateien:

cp -HR include/asm /usr/include
cp -R include/asm-generic /usr/include

Installieren sie die Cross-Plattform Header Dateien:

cp -R include/linux /usr/include

Einige Kernel Header Dateien benutzen die Header Datei autoconf.h. Da wir den Kernel jetzt aber noch nicht konfigurieren, müssen wir die Datei selber erstellen um Compilerfehler zu vermeiden. Erstellen sie eine leere autoconf.h Datei:

touch /usr/include/linux/autoconf.h

Warum wir die Kernel Header kopieren und nicht symbolisch linken

Früher war es gängige Praxis, das Verzeichnis /usr/include/{linux,asm} nach /usr/src/linux/include/{linux,asm} symbolisch zu verlinken. Das war aber schlechte Praxis, wie der folgende Ausschnitt aus einem Posting von Linus Torvalds auf der Linux Kernel Mailinglist zeigt:

I would suggest that people who compile new kernels should: 

 - not have a single symbolic link in sight (except the one that the 
   kernel build itself sets up, namely the "linux/include/asm" symlink 
   that is only used for the internal kernel compile itself) 

And yes, this is what I do. My /usr/src/linux still has the old 2.2.13 
header files, even though I haven't run a 2.2.13 kernel in a _loong_ 
time. But those headers were what Glibc was compiled against, so those 
headers are what matches the library object files. 

And this is actually what has been the suggested environment for at 
least the last five years. I don't know why the symlink business keeps 
on living on, like a bad zombie. Pretty much every distribution still 
has that broken symlink, and people still remember that the linux 
sources should go into "/usr/src/linux" even though that hasn't been 
true in a _loong_ time.

Der wichtige Teil ist, wo Linux sagt, das die Header Dateien die sein sollen, mit denen Glibc kompiliert wurde. Das sind die Header Dateien die zum späteren kompilieren von Paketen verwendet werden sollten, weil nur diese exakt auf die Objekt Code Bibliotheken passen. Durch das kopieren der Header stellen wir sicher, das sie verfügbar bleiben falls sie später den Kernel updaten.

Beachten sie, das es vollkommen in Ordnung ist, die Kernel Sourcen in /usr/src/linux liegen zu haben, so lange sie nicht die symbolischen Links /usr/include/{linux,asm} haben.

Inhalt von Man-pages

Die Hilfeseiten (man-pages) enthalten über 1200 Seiten Hilfetexte. Die Dokumentation beschreibt sehr detailliert C und C++ Funktionen, einige wichtige Gerätedateien und enthält Dokumente die in anderen Paketen sonst fehlen würden.

Installierte Dateien: verschiedene Hilfeseiten

Man-pages Installationsabhängigkeiten

Man ist abhängig von: Bash, Coreutils, Make.

Installation der Man-pages

Installieren sie die Man-pages durch ausführen von:

make install

Inhalt von Glibc

Glibc ist die C Bibliothek, sie stellt Systemaufrufe und grundlegende Funktionen wie open, malloc, printf usw. zur Verfügung. Die C Bibliothek wird von allen dynamisch gelinkten Programmen verwendet.

Installierte Programme: catchsegv, gencat, getconf, getent, glibcbug, iconv, iconvconfig, ldconfig, ldd, lddlibc4, locale, localedef, mtrace, nscd, nscd_nischeck, pcprofiledump, pt_chown, rpcgen, rpcinfo, sln, sprof, tzselect, xtrace, zdump und zic

Installierte Bibliotheken: ld.so, libBrokenLocale.[a,so], libSegFault.so, libanl.[a,so], libbsd-compat.a, libc.[a,so], libc_nonshared.a, libcrypt.[a,so], libdl.[a,so], libg.a, libieee.a, libm.[a,so], libmcheck.a, libmemusage.so, libnsl.a, libnss_compat.so, libnss_dns.so, libnss_files.so, libnss_hesiod.so, libnss_nis.so, libnss_nisplus.so, libpcprofile.so, libpthread.[a,so], libresolv.[a,so], librpcsvc.a, librt.[a,so], libthread_db.so und libutil.[a,so]

Glibc Installationsabhängigkeiten

Glibc ist abhängig von: Bash, Binutils, Coreutils, Diffutils, Gawk, GCC, Gettext, Grep, Make, Perl, Sed, Texinfo.

Installation von Glibc

Das Glibc Installatinssystem ist sehr eigenständig und installiert perfekt, selbst wenn unsere Compiler Specs Datei und der Linker immer noch auf /tools zeigen. Wir können die Specs Datei und den Linker nicht vor der Installation von Glibc anpassen, weil die Glibc Autoconf Tests dann falsche Resultate ergeben würden.

Bevor sie mit dem kompilieren von Glibc beginnen, denken sie daran Glibc-linuxthreads in dem glibc-2.3.2 Verzeichnis zu entpacken, und setzen sie alle Umgebungsvariablen zurück die die standard Optimierungen übergehen würden.

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

touch /etc/ld.so.conf

Dann wenden sie den gleichen Patch an den wir schon früher verwendet haben:

patch -Np1 -i ../glibc-2.3.2-sscanf-1.patch

Die Glibc Dokumentation empfiehlt, Glibc nicht im Quellenverzeichnis, sondern stattdessen in einem dedizierten Kompilierverzeichnis zu bauen:

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

Bereiten sie nun Glibc zum kompilieren vor:

../glibc-2.3.2/configure --prefix=/usr \
    --disable-profile --enable-add-ons \
    --libexecdir=/usr/bin --with-headers=/usr/include

Die Bedeutung der neuen configure Optionen:

• --libexecdir=/usr/bin: Das wird das pt_chown Programm in /usr/bin installieren.

• --with-headers=/usr/include: Das stellt sicher, das die Kernel Header in /usr/include zum kompilieren benutzt werden. Wenn sie diese Option nicht angeben, werden die Header aus /tools/include benutzt, was nicht ideal wäre (auch wenn sie identisch sein sollten). Diese Option hat auch den Vorteil das sie sofort merken, wenn sie vergessen haben sollten, die Kernel Header in /usr/include zu installieren.

Kompilieren sie das Paket:

make

Testen sie das Ergebnis:

make check

Die Anmerkungen zur Test-suite aus dem Abschnitt namens Installieren von Glibc-2.3.2 in Kapitel 5 gelten natürlich auch hier. Schlagen sie dort nach falls sie irgendwelche Zweifel haben.

Und installieren sie das Paket:

make install

Die locales wurden durch das obige Kommando nicht installiert. Holen sie das nach:

make localedata/install-locales

Eine alternative zum obigen Kommando wäre, nur die benötigten oder gewollten locales zu installieren. Das erreichen sie mit dem localedef Befehl. Informationen dazu finden sie in der INSTALL Datei im glibc-2.3.2 Verzeichnisbaum. Einige locales sind allerdings essentiell für die Tests einiger nachfolgender Pakete. Die nachfolgenden Kommandos anstelle des obigen installieren nur ein Minimum an locales so das die Tests sauber durchlaufen:

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

Schlussendlich erzeugen wir die linxthreads Manpages:

make -C ../glibc-2.3.2/linuxthreads/man

Und installieren die Pakete:

make -C ../glibc-2.3.2/linuxthreads/man install

Konfigurieren von Glibc

Wir müssen die Datei /etc/nsswitch.conf erstellen, denn obwohl Glibc Standardwerte vorgibt falls die Datei fehlt oder kaputt ist, funktionieren diese nicht gut mit Netzwerken. Und wir müssen die Zeitzone korrekt einrichten.

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

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

passwd: files
group: files
shadow: files

publickey: files

hosts: files dns
networks: files

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

netgroup: db files

# End /etc/nsswitch.conf
EOF

Um herauszufinden in welcher Zeitzone sie sind, führen sie das folgende Skript aus:

tzselect

Wenn sie ein paar Fragen zu ihrer Lokation 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/Canada/Eastern /etc/localtime 

Die Bedeutung der Option:

• --remove-destination: Dadurch wird das entfernen des bereits existierenden symbolischen Links erzwungen. Der Grund warum wir kopieren anstatt einen symbolischen Link zu benutzen ist, falls /usr auf einer separaten Partition liegt. Das könnte z. B. wichtig werden, wenn in den Single User Modus gebootet wird.

Anstelle von Canada/Eastern müssen sie natürlich den Namen der Zeitzone einsetzen den ihnen tzselect ausgeben hat.

Konfigurieren des dynamischen Laders

Standardmässig such der dynamisch 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 Verzeichnisse in /etc/ld.so.conf einfügen damit der dynamische Lader diese finden kann. Zwei Verzeichnisse die dafür bekannt sind, weitere Bibliotheken zu enthalten, sind /usr/local/lib und /opt/lib, also fügen wir diese Verzeichnisse 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

Inhalt von Binutils

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

Installierte Programme: addr2line, ar, as, c++filt, gprof, ld, nm, objcopy, objdump, ranlib, readelf, size, strings und strip

Installierte Bibliotheken: libiberty.a, libbfd.[a,so] und libopcodes.[a,so]

Binutils Installationsabhängigkeiten

Binutils ist abhängig von: Bash, Coreutils, Diffutils, GCC, Gettext, Glibc, Grep, Make, Perl, Sed, Texinfo.

Installation von Binutils

Jetzt ist ein guter Zeitpunkt um zu überprüfen das pseudo Terminals (PTYs) in ihrer chroot Umgebung funktionieren. Mit dem folgenden schnellen Test überprüfen wir ob alles korrekt konfiguriert ist:

expect -c "spawn ls"

Wenn sie die Nachricht:

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

erhalten, sind PTYs nicht korrekt konfiguriert. In dem Fall macht es keinen Sinn, die Tests für Binutils und GCC laufen zu lassen solange sie das Problem nicht behoben haben. Schlagen sie bitte im Abschnitt namens Einhängen des proc- und devpts Dateisystems und im Abschnitt namens Erstellen der Gerätedateien (Makedev-1.7) nach und führen sie die empfohlenen Schritte durch um das Problem zu beseitigen.

Es ist bekannt, das dieses Paket nicht gut funktioniert wenn sie die standard Optimierungen (inklusive der -march und -mcpu Optionen) geändert haben. Wenn sie Umgebungsvariablen wie CFLAGS oder CXXFLAGS gesetzt haben, empfehlen wir, diese zum installieren von Binutils zurückzusetzen.

Die Binutils Dokumentation empfiehlt, Binutils nicht im Quell-, sondern in einem dedizierten Kompilierverzeichnis zu kompilieren:

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

Bereiten sie Binutils jetzt zum kompilieren vor:

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

Kompilieren sie das Paket:

make tooldir=/usr

Normalerweise ist tooldir (das Verzeichnis wo die ausführbaren Dateien hineininstalliert werden) auf $(exec_prefix)/$(target_alias) gesetzt, welches dann zum Beispiel zu /usr/i686-pc-linux-gnu erweitert wird. Da wir aber nur für unser eigenes System installieren brauchen wir dieses spezielle Verzeichnis 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).

Testen sie das Ergebnis:

make check

Die Anmerkungen zur Test-suite aus dem Abschnitt namens Installieren von Binutils-2.14 - Durchlauf 2 in Kapitel 5 sind hier immer noch gültig. Schlagen sie nach falls sie irgendwelche Bedenken oder Zweifel haben.

Installieren sie das Paket:

make tooldir=/usr install

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

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

Inhalt von GCC

Das Paket GCC enthält die Gnu Compiler Sammlung, inklusive dem C und C++ Compiler.

Installierte Programme: c++, cc (Link auf gcc), cc1, cc1plus, collect2, cpp, g++, gcc, gccbug, und gcov

Installierte Bibliotheken: libgcc.a, libgcc_eh.a, libgcc_s.so, libstdc++.[a,so] und libsupc++.a

GCC Installationsabhängigkeiten

GCC ist abhängig von: Bash, Binutils, Coreutils, Diffutils, Findutils, Gawk, Gettext, Glibc, Grep, Make, Perl, Sed, Texinfo.

Installation von GCC

Es ist bekannt, das dieses Paket nicht sauber funktioniert wenn die standard Optimierungseinstellungen (inklusive der -march und -mcpu Optionen) verändert wurden. Deshalb sollten sie event. gesetzte Umgebungsvariablen die die Standard Optimierung überschreiben - zum Beispiel CFLAGS und CXXFLAGS - für den Kompiliervorgang von GCC zurücksetzen oder entsprechend abändern.

Dieses mal werden wir sowohl den C als auch den C++ Compiler erzeugen, sie müssen also die GCC-core und GCC-g++ Tar-Archive entpacken -- sie entpacken sich automatisch in das selbe Verzeichnis. Genauso sollten sie auch das GCC-testsuite Archiv entpacken. Das vollständige GCC Paket enthält noch mehr Compiler. Eine Anleitung wie sie diese bauen können finden sie unter http://www.linuxfromscratch.org/blfs/view/stable/general/gcc.html.

patch -Np1 -i ../gcc-3.3.1-no_fixincludes-2.patch
patch -Np1 -i ../gcc-3.3.1-suppress-libiberty.patch

Der zweite Patch verhindert die Installation von libiberty von GCC, weil wir stattdessen die Version von Binutils verwenden. Geben sie acht das sie hier nicht den GCC specs Patch aus Kapitel 5 anwenden.

Die GCC Dokumentation empfiehlt, GCC nicht im Quellenverzeichnis sondern in einem dedizierten Kompilierverzeichnis zu kompilieren:

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

Bereiten sie nun GCC zum kompilieren vor:

../gcc-3.3.1/configure --prefix=/usr \
    --enable-shared --enable-threads=posix \
    --enable-__cxa_atexit --enable-clocale=gnu \
    --enable-languages=c,c++

Kompilieren sie das Paket:

make

Testen sie das Ergebnis, aber halten sie bei Fehlern nicht an (sie erinnern sich an die paar bekannten):

make -k check

Die Test-suite Anmerkungen aus dem Abschnitt namens Installieren von GCC-3.3.1 - Durchlauf 2 in Kapitel 5 gelten auch hier noch. Schlagen sie dort nach falls sie irgendwelche Zweifel haben.

Und installieren sie das Paket:

make install

Einige Pakete erwarten das der C PreProzessor im /lib Verzeichnis installiert ist. Um diesen Paketen Rechnung zu tragen erzeugen sie diesen symbolischen Link:

ln -s ../usr/bin/cpp /lib

Viele Pakete benutzen den Namen cc um den C Compiler aufzurufen. Um diese Pakete zufriedenzustellen erzeugen wir einen weiteren symbolischen Link:

ln -s gcc /usr/bin/cc

Inhalt von Coreutils

Das Paket Coreutils enthält eine große Anzahl von Shell Werkzeugen.

Installierte Programme: basename, cat, chgrp, chmod, chown, chroot, cksum, comm, cp, csplit, cut, date, dd, df, dir, dircolors, dirname, du, echo, env, expand, expr, factor, false, fmt, fold, groups, head, hostid, hostname, id, install, join, kill, link, ln, logname, ls, md5sum, mkdir, mkfifo, mknod, mv, nice, nl, nohup, od, paste, pathchk, pinky, pr, printenv, printf, ptx, pwd, readlink, rm, rmdir, seq, sha1sum, shred, sleep, sort, split, stat, stty, su, sum, sync, tac, tail, tee, test, touch, tr, true, tsort, tty, uname, unexpand, uniq, unlink, uptime, users, vdir, wc, who, whoami und yes

Coreutils Installationsabhängigkeiten

Coreutils ist abhängig von: Bash, Binutils, Coreutils, Diffutils, GCC, Gettext, Glibc, Grep, Make, Perl, Sed.

Installation von Coreutils

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

patch -Np1 -i ../coreutils-5.0-uname.patch

Wir möchten nicht, das Coreutils seine Version von hostname installiert, weil sie schlechter ist als die von Net-tools bereitgestellte. Verhindern sie die Installation mit dem folgenden Patch:

patch -Np1 -i ../coreutils-5.0-hostname-2.patch

Bereiten sie Coreutils zum kompilieren vor:

./configure --prefix=/usr

Kompilieren sie das Paket:

make

Das Programm su aus Coreutils wurde in Kapitel 5 nicht installiert weil man dazu root Rechte benötigt. Wir brauchen es aber gleich für die Test-suite. Daher installieren wir es nun:

make install-root

Dieses Paket hat eine Test-suite mit der sie überprüfen können ob alles korrekt kompiliert wurde. Diese Test-suite macht einige Annahmen in Hinsicht auf die Existenz von nicht-root Benutzern und Gruppen und diese sind in in unserem LFS System noch nicht vorhanden. Wir erstellen nun einen dummy System Benutzer und zwei dummy Gruppen damit die Tests sauber durchlauen können. Falls sie diese Test-suite nicht ausführen möchten, überspringen sie sie und fahren sie mit "Installieren sie das Paket" fort. Das folgende Kommando bereitet uns auf das ausführen der Test-suite vor. Erstellen sie zwei dummy Gruppen und einen dummy Benutzernamen:

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

Ein paar Tests müssen als root ausgeführt werden:

make check-root

Die verbleibenden Tests werden als dummy Benutzer ausgeführt:

su dummy -c "make RUN_EXPENSIVE_TESTS=yes check"

Entfernen sie die dummy Gruppen und Benutzer:

sed -i.bak '/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/{dir,dircolors,du,date,echo,false,head} /bin
mv /usr/bin/{install,ln,ls,mkdir,mkfifo,mknod,mv,pwd} /bin
mv /usr/bin/{rm,rmdir,shred,sync,sleep,stty,su,test} /bin
mv /usr/bin/{touch,true,uname,vdir} /bin
mv /usr/bin/chroot /usr/sbin

Schliesslich erstellen sie noch ein paar nötige symbolische Links:

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

Inhalt von Zlib

Zlib enthält die Bibliothek libz. Sie wird von vielen Programmen zum komprimieren und dekomprimieren genutzt.

Installierte Bibliotheken: libz[a,so]

Zlib Installationsabhängigkeiten

Zlib ist abhängig von: Binutils, Coreutils, GCC, Glibc, Make, Sed.

Installation von Zlib

Zlib enthält einen potentiellen Pufferüberlauf in der gzprintf() Funktion, welcher, wenn er auch schwierig auszunutzen ist, durch den folgenden Patch behoben werden sollte:

patch -Np1 -i ../zlib-1.1.4-vsnprintf.patch

Bereiten sie Zlib zum kompilieren vor:

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

Vorsicht: Zlib baut seine gemeinsamen Bibliotheken falsch wenn die CFLAGS Umgebungsvariable gesetzt ist. Wenn sie die CFLAGS Umgebungsvariable verwenden, fügen sie ihr während dem bauen und der Installation von Zlib -fPIC an und entfernen sie es später wieder.

Kompilieren sie das Paket:

make

Installieren sie die gemeinsamen Bibliotheken:

make install

Kompilieren sie nun die nicht-gemeinsamen Bibliotheken:

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

Dieses Paket enthält eine Test-suite um zu prüfen ob alles korrekt kompiliert wurde. Wenn sie sie ausführen möchten, erledigt dies das folgende Kommando für sie:

make test

Und installieren sie das Paket:

make install

Die gemeinsame Zlib Bibliothek sollte in /lib installiert werden. Auf diese Weise haben beim booten, während /usr möglicherweise noch nicht verfübar ist, Systemprogramme trotzdem Zugriff zu dieser Bibliothek:

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

Der symbolische Link /usr/lib/libz.so zeigt auf eine Datei die nicht mehr existiert, weil wir sie gerade verschoben haben. Erstellen sie den symbolischen Link neu, so dass er auf den neuen Standort der Bibliothek zeigt:

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

Zlib installiert seine Man-pages nicht. Holen sie das mit dem folgenden Kommando nach:

cp zlib.3 /usr/share/man/man3

Inhalt von Lfs-Utils

Das Lfs-Utils Paket enthält ein paar Programme die von verschiedenen Paketen gebraucht werden, aber nicht gross genug sind um ein eigenes Paket zu rechtfertigen.

Installierte Programme: mktemp, tempfile, http-get und iana-net

Installierte Dateien: protocols, services

Lfs-Utils Installationsabhängigkeiten

(No dependencies checked yet.)

Installation von Lfs-Utils

Kompilieren sie das Paket:

make

Und installieren sie es:

make install

Kopieren sie noch zwei mitgelieferte Hilfsdateien aus dem Lfs-Utils Archiv an die richtige Stelle:

cp etc/{services,protocols} /etc

Die Datei /etc/services wird zum auflösen von Service Nummern in lesbare Namen verwendet, und /etc/protocols erfüllt den gleichen Zweck für Protokollnummern.

Inhalt von Findutils

Das Findutils Paket enthält Programme zum auffinden von Dateien, entweder on-the-fly (indem ein Verzeichnisbaum live durchsucht wird) oder durch Suche in einer Datenbank.

Installierte Programme: bigram, code, find, frcode, locate, updatedb und xargs

Findutils Installationsabhängigkeiten

Findutils ist abhängig von: Bash, Binutils, Coreutils, Diffutils, GCC, Gettext, Glibc, Grep, Make, Sed.

Installation von Findutils

Bereiten sie Findutils zum kompilieren vor:

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

Standardmässig liegt die updatedb Datenbank in /usr/var. Um FHS Konform zu sein wird die Datei aber in /var/lib/misc/locatedb abgelegt. Daher wird die configure Option --localstatedir=/var/lib/misc angegeben.

Kompilieren sie das Paket:

make

Dieses Paket enthält eine Test-suite um zu prüfen ob alles korrekt kompiliert wurde. Wenn sie die Tests durchlaufen lassen möchten, führen sie dieses Kommando aus:

make check

Und installieren sie das Paket:

make install

Inhalt von Gawk

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

Installierte Programme: awk (Link auf gawk), gawk, gawk-3.1.3, grcat, igawk, pgawk, pgawk-3.1.3 und pwcat

Gawk Installationsabhängigkeiten

Gawk ist abhängig von: Bash, Binutils, Coreutils, Diffutils, GCC, Gettext, Glibc, Grep, Make, Sed.

Installation von Gawk

Als erstes wenden sie einen Patch an um die folgenden Probleme zu beseitigen:

• Gawk's Standard Platz für einige seiner ausführbaren Dateien ist $prefix/libexec/awk. Dieser Pfad ist nicht konform mit dem FHS, welches ein Verzeichnis namens libexec noch nicht einmal erwähnt. Der Patch ermöglicht es, die --libexecdir Option an das configure Skript zu übergeben, sodass wir einen passenderen Ort für grcat und pwcat verwenden können: /usr/bin.

• Gawk's Standard Datenverzeichnis ist $prefix/share/awk. Aber Paketspezifische Verzeichnisse sollten den Paketnamen und die Versionsnummer enthalten (zum Beispiel gawk-7.7.2.) und nicht einfach nur den Paketnamen, denn es könnten verschiedene Versionen dieses Pakets auf dem System installiert sein. Der Patch ändert den Namen des Datenverzeichnisses auf den korrekten Namen $prefix/share/gawk-3.1.3.

• Der Patch stellt ausserdem sicher, das dieses Datenverzeichnis beim Aufruf von make uninstall wieder entfernt wird.

patch -Np1 -i ../gawk-3.1.3-libexecdir.patch

Bereiten sie nun Gawk zum kompilieren vor:

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

Kompilieren sie das Paket:

make

Dieses Paket enthält eine Test-suite um zu prüfen ob alles korrekt kompiliert wurde. Wenn sie sie ausführen möchten, erledigt dies das folgende Kommando für sie:

make check

Und installieren sie das Paket:

make install

Inhalt von Ncurses

Ncurses enthält Bibliotheken zur Verwendung von Zeichen und Terminals, inklusive Schaltflächen und Menüs.

Installierte Programme: captoinfo (Link auf tic), clear, infocmp, infotocap (Link auf tic), reset (Link auf tset), tack, tic, toe, tput und tset

Installierte Bibliotheken: libcurses.[a,so] (Link auf libncurses.[a,so]), libform.[a,so], libmenu.[a,so], libncurses++.a, libncurses.[a,so], libpanel.[a,so]

Ncurses Installationsabhängigkeiten

Ncurses ist abhängig von: Bash, Binutils, Coreutils, Diffutils, Gawk, GCC, Glibc, Grep, Make, Sed.

Installation von Ncurses

Beheben sie zuerst zwei kleine Fehler:

patch -Np1 -i ../ncurses-5.3-etip-2.patch
patch -Np1 -i ../ncurses-5.3-vsscanf.patch

Der erste Patch korrigiert die Header Datei etip.h, und der zweite Patch verhindert einige Compiler Warnung über alte, missbilligte Header Dateien.

Bereiten sie Ncurses nun zum kompilieren vor:

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

Kompilieren sie das Paket:

make

Installieren sie das Paket:

make install

Geben sie der Ncurses Bibliothek Ausführrechte:

chmod 755 /usr/lib/*.5.3

Und korrigieren sie eine Bibltiothek die nicht ausführbar sein sollte:

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

Verschieben sie die Bibltiotheken in das /lib Verzeichnis, denn es wird erwartet das sie sich dort befinden:

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

Da die Bibliotheken nach /lib verschoben wurden, zeigen ein paar symbolische Links ins Leere. Ertellen sie diese Links neu:

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

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/stable/postlfs/editors.html, dort finden sie einige Installationshinweise.

Inhalt von Vim

Vim enthält einen sehr anpassungsfähigen Text Editor, extra programmiert zum effizienten bearbeiten von Text.

Installierte Programme: efm_filter.pl, efm_perl.pl, ex (Link auf vim), less.sh, mve.awk, pltags.pl, ref, rview (Link auf vim), rvim (Link auf vim), shtags.pl, tcltags, vi (Link auf vim), view (Link auf vim), vim, vim132, vim2html.pl, vimdiff (Link auf vim), vimm, vimspell.sh, vimtutor und xxd

Vim Installationsabhängigkeiten

Vim ist abhängig von: Bash, Binutils, Coreutils, Diffutils, GCC, Glibc, Grep, Make, Ncurses, Sed.

Installation von Vim

Ändern sie den Standardpfad von 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

Kompilieren sie das Paket:

make

Und installieren sie das Paket:

make install

Vim kann im klassischen vi Modus laufen indem sie einen symbolischen Link erzeugen:

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

Konfigurieren von Vim

Standardmässig läuft vim im vi Kompatibilitätsmodus. Einige Leute mögen das so, aber wir würden vim gern im vim Modus ausführen (sonst hätten wir vim nicht in diesem Buch installiert, sondern gleich vi). Erstellen sie die Datei /root/.vimrc mit dem folgenden Kommando:

cat > /root/.vimrc << "EOF"
" Begin /root/.vimrc

set nocompatible
set bs=2

" End /root/.vimrc
EOF

Inhalt von M4

M4 ist ein Makroprozessor. Er kopiert die Eingabe zur Ausgabe und führt dabei Makros aus. Die Makros können entweder vordefiniert oder selbstgeschrieben sein und können beliebige Argumente übernehmen. Neben der Fähigkeit Makros auszuführen hat M4 eingaute Funktionen um benannte Dateien einzufügen, Unix Kommandos auszuführen, Integer Berechnungen durchzuführen, Text zu manipulieren, Rekursionen zu behandeln usw. M4 kann entweder als Front-end zu einem Compiler oder als eigenständiger Makroprozessor genutzt werden.

Installierte Programme: m4

M4 Installationsabhängigkeiten

M4 ist abhängig von: Bash, Binutils, Coreutils, Diffutils, GCC, Gettext, Glibc, Grep, Make, Perl, Sed.

Installation von M4

Bereiten sie M4 zum kompilieren vor:

./configure --prefix=/usr

Kompilieren sie das Paket:

make

Dieses Paket enthält eine Test-suite um zu prüfen ob alles korrekt kompiliert wurde. Wenn sie sie ausführen möchten, erledigt dies das folgende Kommando für sie:

make check

Und installieren sie das Paket:

make install

Inhalt von Bison

Bison ist ein Programm zum erstellen von Analysatoren, ein Ersatz für yacc. Bison erstellt ein Programm welches die Struktur einer Textdatei analysiert.

Installierte Programme: bison und yacc

Installierte Bibliotheken: liby.a

Bison Installationsabhängigkeiten

Bison ist abhängig von: Bash, Binutils, Coreutils, Diffutils, GCC, Gettext, Glibc, Grep, M4, Make, Sed.

Installation von Bison

Zuerst wenden wir einen Patch an, der aus dem CVS zurückportiert wurde, um ein kleines Problem beim kompilieren einiger Pakete zu beheben:

patch -Np1 -i ../bison-1.875-attribute.patch

Bereiten sie Bison zum kompilieren vor:

./configure --prefix=/usr

Kompilieren sie das Paket:

make

Dieses Paket enthält eine Test-suite um zu prüfen ob alles korrekt kompiliert wurde. Falls sie diese Tests ausführen möchten, benutzen sie dieses Kommando:

make check

Und installieren sie das Paket:

make install

Inhalt von Less

Less ist ein Textanzeigeprogramm. Es zeigt den Inhalt von Dateien oder Datenströmen an. Less hat einige Merkmale die more nicht hat, wie zum Beispiel die Möglichkeit rückwärts zu scrollen.

Installierte Programme: less, lessecho und lesskey

Less Installationsabhängigkeiten

Less ist abhängig von: Bash, Binutils, Coreutils, Diffutils, GCC, Glibc, Grep, Make, Ncurses, Sed.

Installation von Less

Bereiten sie Less zum kompilieren vor:

./configure --prefix=/usr --bindir=/bin --sysconfdir=/etc

Die Bedeutung der configure Option:

• --sysconfdir=/etc: Diese Option bewirkt, das die in diesem Paket installierten Programme ihre Konfigurationsdateien in /etc suchen.

Kompilieren sie das Paket:

make

Und installieren sie es:

make install

Inhalt von Groff

Groff enthält verschiedene Programme zur verarbeitung und formatierung von Text. Groff konvertiert normalen Text mit speziellen Kommandos in eine formatierte Ausgabe, so wie man es zum Beispiel in den Hilfeseiten (man-pages) sieht.

Installierte Programme: addftinfo, afmtodit, eqn, eqn2graph, geqn (Link auf eqn), grn, grodvi, groff, groffer, grog, grolbp, grolj4, grops, grotty, gtbl (Link auf tbl), hpftodit, indxbib, lkbib, lookbib, mmroff, neqn, nroff, pfbtops, pic, pic2graph, post-grohtml, pre-grohtml, refer, soelim, tbl, tfmtodit, troff and zsoelim (Link auf soelim)

Groff Installationsabhängigkeiten

Groff ist abhängig von: Bash, Binutils, Coreutils, Diffutils, Gawk, GCC, Glibc, Grep, Make, Sed.

Installation von Gross

Groff erwartet, das die Umgebungsvariable PAGE die standard Papiergröße enthält. Für alle in den Vereinigten Staaten ist das untenstehende Kommando so korrekt. Wenn sie woanders leben ersetzen sie besser PAGE=letter durch PAGE=A4.

Bereiten sie Groff zum kompilieren vor:

PAGE=letter ./configure --prefix=/usr

Kompilieren sie das Paket:

make

Und installieren sie es:

make install

Eine Dokumentationsprogramme wie zum Beispiel xman funktionieren ohne diese symbolischen Links nicht:

ln -s soelim /usr/bin/zsoelim
ln -s eqn /usr/bin/geqn
ln -s tbl /usr/bin/gtbl

Inhalt von Sed

Sed ist ein Stream Editor. Mit einem Stream Editor kann man einfache Textmanipulationen an einem Eingabestream vornehmen (z. B. einer Datei oder einer Pipe).

Installiertes Programm: sed

Sed Installationsabhängigkeiten

Sed ist abhängig von: Bash, Binutils, Coreutils, Diffutils, GCC, Gettext, Glibc, Grep, Make, Texinfo.

Installation von Sed

Bereiten sie Sed zum kompilieren vor:

./configure --prefix=/usr --bindir=/bin

Kompilieren sie das Paket:

make

Dieses Paket enthält eine Test-suite um zu prüfen ob alles korrekt kompiliert wurde. Wenn sie sie ausführen möchten, erledigt dies das folgende Kommando für sie:

make check

Und installieren sie das Paket:

make install

Inhalt von Flex

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

Installierte Programme: flex, flex++ (Link auf flex) und lex

Installierte Bibliothek: libfl.a

Flex Installationsabhängigkeiten

Flex ist abhängig von: Bash, Binutils, Bison, Coreutils, Diffutils, GCC, Gettext, Glibc, Grep, M4, Make, Sed.

Installation von Flex

Bereiten sie Flex zum kompilieren vor:

./configure --prefix=/usr

Kompilieren sie das Paket:

make

Dieses Paket enthält eine Test-suite um zu prüfen ob alles korrekt kompiliert wurde. Wenn sie sie ausführen möchten, erledigt dies das folgende Kommando für sie:

make bigcheck

Und installieren sie das Paket:

make install

Es existieren einige Programme die die Lex Bibliothek in /usr/lib erwarten. Erstellen sie daher einen entsprechenden symbolischen Link:

ln -s libfl.a /usr/lib/libl.a

Einige wenige Programme kennen flex noch nicht und versuchen seinen Vorgänger lex aufzurufen. Um diese Programme dennoch zu unterstützen erzeugen sie ein kleine Shell Skript mit dem Namen lex das flex im Emulationsmodus aufruft:

cat > /usr/bin/lex << "EOF"
#!/bin/sh
# Begin /usr/bin/lex

exec /usr/bin/flex -l "$@"

# End /usr/bin/lex
EOF
chmod 755 /usr/bin/lex

Inhalt von Gettext

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

Installierte Programme: autopoint, config.charset, config.rpath, gettext, gettextize, hostname, msgattrib, msgcat, msgcmp, msgcomm, msgconv, msgen, msgexec, msgfilter, msgfmt, msggrep, msginit, msgmerge, msgunfmt, msguniq, ngettext, project-id, team-address, trigger, urlget, user-email und xgettext

Installierte Bibliotheken: libasprintf[a,so], libgettextlib[a,so], libgettextpo[a,so] und libgettextsrc[a,so]

Gettext Installationsabhängigkeiten

Gettext ist abhängig von: Bash, Binutils, Bison, Coreutils, Diffutils, Gawk, GCC, Glibc, Grep, Make, Sed.

Installation von Gettext

Bereiten sie Gettext zum kompilieren vor:

./configure --prefix=/usr

Kompilieren sie das Paket:

make

Dieses Paket enthält eine Test-suite um zu prüfen ob alles korrekt kompiliert wurde. Wenn sie sie ausführen möchten, erledigt dies das folgende Kommando für sie (das benötigt sehr viel Zeit):

make check

Und installieren sie das Paket:

make install

Inhalt von Net-tools

Die Net-tools sind eine Sammlung von grundlegenden Programmen für das Netzwerk unter Linux.

Installierte Programme: arp, dnsdomainname (Link auf hostname), domainname (Link auf hostname), hostname, ifconfig, nameif, netstat, nisdomainname (Link auf hostname), plipconfig, rarp, route, slattach und ypdomainname (Link auf hostname)

Net-tools Installationsabhängigkeiten

Net-tools ist abhängig von: Bash, Binutils, Coreutils, GCC, Glibc, Make.

Installation von Net-tools

Wenn sie nicht wissen was sie während dem ausführen von make config auf die Fragen antworten sollten, dann akzeptieren sie einfach den Vorgabewert. Das ist in den meisten Fällen richtig. Sie werden einige Fragen gestellt bekommen welche Netzwerkprotokolle sie im Kernel aktiviert haben. Die Standardantworten aktivieren die Programme mit den gängigen Protokollen TCP, PPP und einigen anderen. Sie müssen diese Protokolle dann noch im Kernel aktivieren -- was sie hier tun ist nur die Vorbereitung der Programme damit sie diese Protokolle später benutzen können, aber es ist immer noch Sache des Kernels diese Protokolle auch wirklich zur Verfügung zu stellen.

Beheben sie zuerst ein kleines Problem in den Quellen des mii Hilfsprogramm:

patch -Np1 -i ../net-tools-1.60-miitool-gcc33-1.patch

Bereiten sie nun Net-tools zum kompilieren vor:

make config

Wenn sie generell die Standardwerte annehmen möchten die ihnen von make config vorgeschlagen werden, dann können sie stattdessen auch yes "" | make config ausführen.

Kompilieren sie das Paket:

make

Und installieren sie es:

make update

Inhalt von Inetutils

Inetutils enthält verschiedene Netzwerk Clients und Server.

Installierte Programme: ftp, ping, rcp, rlogin, rsh, talk, telnet und tftp

Inetutils Installationsabhängigkeiten

Inetutils ist abhängig von: Bash, Binutils, Coreutils, Diffutils, GCC, Glibc, Grep, Make, Ncurses, Sed.

Installation von Inetutils

Bereiten sie Inetutils zum kompilieren vor:

./configure --prefix=/usr --disable-syslogd \
    --libexecdir=/usr/sbin --disable-logger \
    --sysconfdir=/etc --localstatedir=/var \
    --disable-whois --disable-servers

Die Bedeutung der configure Optionen:

• --disable-syslogd: Diese Option verhindert die Installation des System Log Dämonen, weil wir einen mit dem Sysklogd Paket installieren.

• --disable-logger: Das verhindert die Installation des logger Programmes, welches Nachrichten an den System Log Dämonen übergibt. Wir installieren ihn nicht, weil Util-Linux etwas später eine bessere Version installiert.

• --disable-whois: Das verhindert das kompilieren des whois Clients, welcher leider elendig veraltet ist. Eine Anleitung für einen besseren whois Client finden sie im BLFS Buch.

• --disable-servers: Das verhindert die Installation verschiedener Netzwerkserver die dem Inetutils Paket beiliegen. Diese gelten in einem basis LFS-System als nicht angebracht. Einige sind von Natur aus unsicher und nur in vertrauenswürdigen Netzen sicher einsetzbar. Mehr Informationen finden sie unter http://www.linuxfromscratch.org/blfs/view/stable/basicnet/inetutils.html. Beachten sie, das es für fast alle dieser Netzwerkserver einen besseren Ersatz gibt.

Kompilieren sie das Paket:

make

Installieren sie es:

make install

Und verschieben sie das ping Programm an seine korrekte Stelle:

mv /usr/bin/ping /bin

Inhalt von Perl

Das Perl Paket enthält die Skriptsprache Perl (Practical Extraction and Report Language). Perl kombiniert einige der besten Merkmale von C, sed, awk und sh in einer einzigen, mächtigen Skriptsprache.

Installierte Programme: a2p, c2ph, dprofpp, enc2xs, find2perl, h2ph, h2xs, libnetcfg, perl, perl5.8.0 (Link auf perl), perlbug, perlcc, perldoc, perlivp, piconv, pl2pm, pod2html, pod2latex, pod2man, pod2text, pod2usage, podchecker, podselect, psed (Link auf s2p), pstruct (Link auf c2ph), s2p, splain und xsubpp

Installierte Bibliotheken: (zu viele um sie einzeln aufzulisten)

Perl Installationsabhängigkeiten

Perl ist abhängig von: Bash, Binutils, Coreutils, Diffutils, Gawk, GCC, Glibc, Grep, Make, Sed.

Installation von Perl

Bereiten sie Perl zum kompilieren vor:

./configure.gnu --prefix=/usr

Wenn sie mehr Kontrolle über die Art haben möchten wie Perl sich selbst zum installieren konfiguriert, können sie stattdessen das interaktive Configure Skript benutzen. Wenn sie mit den (sinnvollen) Standardwerten zufrieden sind die Perl automatisch erkennt, dann benutzen sie einfach das obige Kommando.

Kompilieren sie das Paket:

make

Dieses Paket enthält eine Test-suite um zu prüfen ob alles korrekt kompiliert wurde. Wenn sie sie ausführen möchten, müssen sie erst eine Basisversion der /etc/hosts Datei erstellen. Diese wird benötigt damit einige der Tests den Hostnamen localhost auflösen können:

echo "127.0.0.1 localhost $(hostname)" > /etc/hosts

Wenn sie möchten können sie nun die Tests ausführen:

make test

Und installieren sie das Paket:

make install

Inhalt von Texinfo

Texinfo enthält Programme zum lesen, schreiben und konvertieren von Info Dokumenten (System Dokumentation).

Installierte Programme: info, infokey, install-info, makeinfo, texi2dvi und texindex

Texinfo Installationsabhängigkeiten

Texinfo ist abhängig von: Bash, Binutils, Coreutils, Diffutils, GCC, Gettext, Glibc, Grep, Make, Ncurses, Sed.

Installation von Texinfo

Bereiten sie Texinfo zum kompilieren vor:

./configure --prefix=/usr

Kompilieren sie das Paket:

make

Dieses Paket enthält eine Test-suite um zu prüfen ob alles korrekt kompiliert wurde. Wenn sie sie ausführen möchten, erledigt dies das folgende Kommando für sie:

make check

Installieren sie das Paket:

make install

Optional können sie die Komponenten installieren die zu einer TeX Installation dazugehören:

make TEXMF=/usr/share/texmf install-tex

Die Bedeutung des make Parameters:

• TEXMF=/usr/share/texmf: Die TEXMF makefile Variable enthält den Standort ihres TeX Verzeichnisbaumes, falls sie zum Beispiel planen später ein TeX Paket zu installieren.

Inhalt von Autoconf

Autoconf erstellt Shell Skripte die Quelltexte automatisch konfigurieren.

Installierte Programme: autoconf, autoheader, autom4te, autoreconf, autoscan, autoupdate und ifnames

Autoconf Installationsabhängigkeiten

Autoconf ist abhängig von: Bash, Coreutils, Diffutils, Grep, M4, Make, Perl, Sed.

Installation von Autoconf

Bereiten sie Autoconf zum kompilieren vor:

./configure --prefix=/usr

Kompilieren sie das Paket:

make

Dieses Paket hat eine Test-suite mit der sie überprüfen können ob alles korrekt kompiliert wurde. Wenn sie sie laufen lassen möchten, führen sie dieses Kommando aus:

make check

Und installieren sie das Paket:

make install

Inhalt von Automake

Automake generiert Makefile.in Dateien, die danach von Autoconf benutzt werden können.

Installierte Programme: acinstall, aclocal, aclocal-1.7, automake, automake-1.7, compile, config.guess, config.sub, depcomp, elisp-comp, install-sh, mdate-sh, missing, mkinstalldirs, py-compile, ylwrap

Automake Installationsabhängigkeiten

Automake ist abhängig von: Autoconf, Bash, Coreutils, Diffutils, Grep, M4, Make, Perl, Sed.

Installation von Automake

Bereiten sie Automake zum kompilieren vor:

./configure --prefix=/usr

Kompilieren sie das Paket:

make

Dieses Paket hat eine Test-suite mit der sie prüfen können ob alles korrekt kompiliert wurde. Benutzen sie dieses Kommando wenn sie sie auszuführen möchten:

make check

Installieren sie das Paket:

make install

Und erzeugen sie einen nötigen symbolischen Link:

ln -s automake-1.7 /usr/share/automake

Inhalt von Bash

Bash ist die "Bourne Again SHell", ein auf Unix Systemen weit verbreiteter Befehlsinterpreter. Die Bash liest Befehle von der Standard Eingabe (der Tastatur). Ein Anwender gibt etwas ein und die Bash wertet die Eingabe aus. Je nach Eingabe reagiert die Bash entsprechend und führt zum Beispiel ein Programm aus.

Installierte Programme: bash, sh (Link auf bash) und bashbug

Bash Installationsabhängigkeiten

Bash ist abhängig von: Binutils, Coreutils, Diffutils, Gawk, GCC, Glibc, Grep, Make, Ncurses, Sed.

Installation von Bash

Bash hat ein paar Fehler die manchmal zu unerwünschten Effekten führen. Beheben sie das Problem mit diesem Patch:

patch -Np1 -i ../bash-2.05b-2.patch

Bereiten sie Bash zum kompilieren vor:

./configure --prefix=/usr --bindir=/bin

Kompilieren sie das Paket:

make

Dieses Paket hat eine Test-suite mit der sie prüfen können ob alles korrekt kompiliert wurde. Wenn sie die Tests durchlaufen möchten, führen sie dieses Kommando aus:

make tests

Installieren sie das Paket:

make install

Und starten sie die frisch installierte bash:

exec /bin/bash --login +h

Inhalt von File

File ist ein kleines Werkzeug zum identifizieren von Dateitypen.

Installiertes Programm: file

Installierte Bibliotheken: libmagic.[a,so]

File Installationsabhängigkeiten

File ist abhängig von: Bash, Binutils, Coreutils, Diffutils, GCC, Glibc, Grep, Make, Sed, Zlib.

Installation von File

Bereiten sie File zum kompilieren vor:

./configure --prefix=/usr

Kompilieren die das Paket:

make

Und installieren sie es:

make install

Inhalt von Libtool

GNU Libtool ist ein Skript zur unterstützung von Bibliotheken. Libtool versteckt die Komplexität von gemeinsam benutzten Bibliotheken hinter einer konsistenten und portablen Schnittstelle.

Installierte Programme: libtool und libtoolize

Installierte Bibliotheken: libltdl.[a,so].

Libtool Installationsabhängigkeiten

Libtool ist abhängig von: Bash, Binutils, Coreutils, Diffutils, GCC, Glibc, Grep, Make, Sed.

Installation von Libtool

Bereiten sie Libtool zum kompilieren vor:

./configure --prefix=/usr

Kompilieren sie das Paket:

make

Dieses Paket enthält eine Test-suite um zu prüfen ob alles korrekt kompiliert wurde. Wenn sie sie ausführen möchten, erledigt dies das folgende Kommando für sie:

make check

Und installieren sie das Paket:

make install

Inhalt von Bzip2

Bzip2 ein Block-sortierendes Kompressionsprogramm und erreicht üblicherweise bessere Kompressionsraten als das herkömmliche gzip.

Installierte Programme: bunzip2 (Link auf bzip2), bzcat (Link auf bzip2), bzcmp, bzdiff, bzegrep, bzfgrep, bzgrep, bzip2, bzip2recover, bzless und bzmore

Installierte Bibliotheken: libbz2.a, libbz2.so (Link auf libbz2.so.1.0), libbz2.so.1.0 (Link auf libbz2.so.1.0.2) und libbz2.so.1.0.2

Bzip2 Installationsabhängigkeiten

Bzip2 ist abhängig von: Bash, Binutils, Coreutils, Diffutils, GCC, Glibc, Make.

Installation von Bzip2

Bereiten sie Bzip2 zum kompilieren vor:

make -f Makefile-libbz2_so
make clean

Der Schalter -f veranlasst Bzip2 ein anderes Makefile, in diesem Fall Makefile-libbz2_so, zu verwenden. Dieses erzeugt eine dynamische Bibliothek libbz2.so und verlinkt die Bzip2 Werkzeuge damit.

Kompilieren sie das Paket:

make

Installieren sie es:

make install

Und installieren sie die ausführbare bzip2 Datei nach /bin. Dann erzeuen sie ein paar nötige symbolische Links und räumen auf:

cp bzip2-shared /bin/bzip2
cp -a libbz2.so* /lib
ln -s ../../lib/libbz2.so.1.0 /usr/lib/libbz2.so
rm /usr/bin/{bunzip2,bzcat,bzip2}
mv /usr/bin/{bzip2recover,bzless,bzmore} /bin
ln -s bzip2 /bin/bunzip2
ln -s bzip2 /bin/bzcat

Inhalt von Diffutils

Die Programme dieses Pakets können die Unterschiede zwischen zwei Dateien oder Verzeichnissen anzeigen. Die häufigste Anwendung ist das erstellen von Software-Patches.

Installierte Programme: cmp, diff, diff3 und sdiff

Diffutils Installationsabhängigkeiten

Diffutils ist abhängig von: Bash, Binutils, Coreutils, Diffutils, GCC, Gettext, Glibc, Grep, Make, Sed.

Installation von Diffutils

Bereiten sie Diffutils zum kompilieren vor:

./configure --prefix=/usr

Kompilieren sie das Paket:

make

Und installieren sie es:

make install

Inhalt von Ed

GNU ed ist ein 8bit-fähiger, POSIX-konformer Editor.

Installierte Programme: ed und red (Link auf ed)

Ed Installationsabhängigkeiten

Ed ist abhängig von: Bash, Binutils, Coreutils, Diffutils, GCC, Glibc, Grep, Make, Sed.

Installation von Ed

Ed verwendet die mktemp Funktion um temporäre Dateien in /tmp zu erstellen, doch diese Funktion ist verwundbar (schauen sie in die Sektion übr temporäre Dateien in http://en.tldp.org/HOWTO/Secure-Programs-HOWTO/avoid-race.html). Der folgende Patch lässt Ed die mkstemp Funktion verwenden, das ist der bevorzugte Weg um temporäre Dateien zu erzeugen.

Wenden sie den Patch an:

patch -Np1 -i ../ed-0.2-mkstemp.patch

Bereiten sie Ed nun zum kompilieren vor:

./configure --prefix=/usr

Kompilieren sie das Paket:

make

Dieses Paket enthält eine Test-suite um zu prüfen ob alles korrekt kompiliert wurde. Wenn sie sie ausführen möchten, erledigt dies das folgende Kommando für sie:

make check

Installieren sie das Paket:

make install

Und verschieben sie die Programme nach /bin damit sie auch dann verwendet werden können, wenn die Partition für /usr nicht verfügbar sein sollte.

mv /usr/bin/{ed,red} /bin

Inhalt von Kbd

Kbd enthält die Dateien für das Tastaturlayout und entsprechende Werkzeuge dazu.

Installiete Programme: chvt, deallocvt, dumpkeys, fgconsole, getkeycodes, getunimap, kbd_mode, kbdrate, loadkeys, loadunimap, mapscrn, openvt, psfaddtable (Link auf psfxtable), psfgettable (Link auf psfxtable), psfstriptable (Link auf psfxtable), psfxtable, resizecons, setfont, setkeycodes, setleds, setlogcons, setmetamode, setvesablank, showconsolefont, showkey, unicode_start und unicode_stop

Kbd Installationsabhängigkeiten

Kbd ist abhängig von: Bash, Binutils, Bison, Coreutils, Diffutils, Flex, GCC, Gettext, Glibc, Grep, Gzip, M4, Make, Sed.

Installation von Kbd

Standardmässig werden einige von Kbd's Hilfprogrammen (setlogcons, setvesablank und getunimap) nicht installiert. Aktivieren sie erst die Installation dieser Programme:

patch -Np1 -i ../kbd-1.08-more-programs.patch

Bereiten sie Kbd zum kompilieren vor:

./configure

Kompilieren sie das Paket:

make

Und installieren es:

make install

Inhalt von E2fsprogs

E2fsprogs stellt die Dateisystemwerkzeuge für die Benutzung des ext2 Dateisystems zur Verfügung. Auch ext3 wird unterstützt, das ist ein Journaling Dateisystem.

Installierte Programme: badblocks, blkid, chattr, compile_et, debugfs, dumpe2fs, e2fsck, e2image, e2label, findfs, fsck, fsck.ext2, fsck.ext3, logsave, lsattr, mk_cmds, mke2fs, mkfs.ext2, mkfs.ext3, mklost+found, resize2fs, tune2fs und uuidgen.

Installierte Bibliotheken: libblkid.[a,so], libcom_err.[a,so], libe2p.[a,so], libext2fs.[a,so], libss.[a,so] und libuuid.[a,so]

E2fsprogs Installationsabhängigkeiten

E2fsprogs ist abhängig von: Bash, Binutils, Coreutils, Diffutils, Gawk, GCC, Gettext, Glibc, Grep, Make, Sed, Texinfo.

Installation von E2fsprogs

Es wird empfohlen, E2fsprogs ausserhalb des Quellverzeichnisses zu kompilieren:

mkdir ../e2fsprogs-build
cd ../e2fsprogs-build

Bereiten sie E2fsprogs zum kompilieren vor:

../e2fsprogs-1.34/configure --prefix=/usr --with-root-prefix="" \
    --enable-elf-shlibs

Die Bedeutung der configure Optionen:

• --with-root-prefix="": Bestimmte Programme (so wie z. B. e2fsck) sind absolut essentielle Programme. Wenn zum Beispiel /usr nicht gemountet ist müssen diese Programme trotzdem verfügbar sein. Sie gehören in Verzeichnisse wie /lib und /sbin. Wenn diese Option nicht an E2fsprogs configure Skript übergeben wird, würden die Programme entgegen unserem Willen im /usr Verzeichnis installiert werden.

• --enable-elf-shlibs: Das erzeugt die gemeinsamen Bibliotheken die einige Programme in diesem Paket verwenden.

Kompilieren sie das Paket:

make

Dieses Paket enthält eine Test-suite um zu prüfen ob alles korrekt kompiliert wurde. Falls sie sie auführen wollen, führen sie dieses Kommando aus:

make check

Installieren sie das meiste aus dem Paket:

make install

Und installieren sie auch die gemeinsamen Bibliotheken:

make install-libs

Inhalt von Grep

Grep zeigt alle Zeilen einer Datei an die auf ein bestimmtes Muster passen.

Installierte Programme: egrep (Link auf grep), fgrep (Link auf grep) und grep

Grep Installationsabhängigkeiten

Grep ist abhängig von: Bash, Binutils, Coreutils, Diffutils, GCC, Gettext, Glibc, Make, Sed, Texinfo.

Installation von Grep

Bereiten sie Grep zum kompilieren vor:

./configure --prefix=/usr --bindir=/bin \
    --with-included-regex

Kompilieren sie das Paket:

make

Dieses Paket enthält eine Test-suite um zu prüfen ob alles korrekt kompiliert wurde. Wenn sie sie ausführen möchten, erledigt dies das folgende Kommando für sie:

make check

Und installieren sie das Paket:

make install

Inhalt von Grub

Das Paket Grub enthält den Grub Bootloader.

Installierte Programme: grub, grub-install, grub-md5-crypt, grub-terminfo und mbchk

Grub Installationsabhängigkeiten

Grub ist abhängig von: Bash, Binutils, Coreutils, Diffutils, GCC, Glibc, Grep, Make, Ncurses, Sed.

Installation von Grub

Es ist bekannt, das dieses Paket nicht sauber funktioniert wenn die standard Optimierungseinstellungen (inklusive der -march und -mcpu Optionen) verändert wurden. Deshalb sollten sie event. gesetzte Umgebungsvariablen die die Standard Optimierung überschreiben - zum Beispiel CFLAGS und CXXFLAGS - für den Kompiliervorgang von Grub zurücksetzen oder entsprechend abändern.

Beheben sie zuerst ein kompilierproblem mit GCC-3.3.1:

patch -Np1 -i ../grub-0.93-gcc33-1.patch

Bereiten sie nun Grub zum kompilieren vor:

./configure --prefix=/usr

Kompilieren sie das Paket:

make

Und installieren sie es:

make install
mkdir /boot/grub
cp /usr/share/grub/i386-pc/stage{1,2} /boot/grub

Ersetzen sie i386-pc durch das für ihre Plattform korrekte Verzeichnis.

Das i386-pc Verzeichnis enthält auch einige *stage1_5 Dateien, jeweils für verschiedene Dateisysteme. Schauen sie nach welche zur Verfügung stehen und kopieren sie die notwendigen nach /boot/grub. Die meisten werden e2fs_stage1_5 und/oder reiserfs_stage1_5 kopieren.

Inhalt von Gzip

Gzip enthält Programme für die Dateikompression und -dekompression mit Hilfe des Lempel-Ziv Algorythmus (LZ77).

Installierte Programme: gunzip (Link auf gzip), gzexe, gzip, uncompress (Link auf gunzip), zcat (Link auf gzip), zcmp, zdiff, zegrep, zfgrep, zforce, zgrep, zless, zmore und znew

Gzip Installationsabhängigkeiten

Gzip ist abhängig von: Bash, Binutils, Coreutils, Diffutils, GCC, Glibc, Grep, Make, Sed.

Installation von Gzip

Bereiten sie Gzip zum kompilieren vor:

./configure --prefix=/usr

Das Programm gzexe bekommt den Pfad zu gzip fest eingebaut. Da wir diese Datei im nachhinein verschieben, müssen wir mit dem folgenden Kommando sicherstellen, das der korrekte Pfad in die Binärdatei geschrieben wird:

cp gzexe.in{,.backup}
sed 's%"BINDIR"%/bin%' gzexe.in.backup > gzexe.in

Kompilieren sie das Paket:

make

Installieren sie das Paket:

make install

Und verschieben sie die Programme in das /bin Verzeichnis:

mv /usr/bin/gzip /bin
rm /usr/bin/{gunzip,zcat}
ln -s gzip /bin/gunzip
ln -s gzip /bin/zcat
ln -s gunzip /bin/uncompress

Inhalt von Man

Man ist das Programm zum Seitenweisen anzeigen von Hilfeseiten (man-pages).

Installierte Programme: apropos, makewhatis, man, man2dvi, man2html und whatis

Man Installationsabhängigkeiten

Man ist abhängig von: Bash, Binutils, Coreutils, Gawk, GCC, Glibc, Grep, Make, Sed.

Installation von Man

Wir nehmen zuerst drei Anpassungen an den Quellen zu Man vor:

Der erste Patch kommentiert die "MANPATH /usr/man" Zeile in man.conf aus. Das verhindert redundante Ergebnisse wenn Programme wie zum Beispiel whatis verwendet werden:

patch -Np1 -i ../man-1.5m2-manpath.patch

Der zweite Patch fügt der PAGER Variable die -R Option hinzu. Dadurch werden Escape Sequenzen korrekt behandelt:

patch -Np1 -i ../man-1.5m2-pager.patch

Der dritte und letzte Patch verhindert ein Problem wenn Manpages mit mehr als 80 Zeichen Zeilenlänge im Zusammenhang mit neueren Groff Versionen formatiert werden:

patch -Np1 -i ../man-1.5m2-80cols.patch

Bereiten sie Man nun zum kompilieren vor:

./configure -default -confdir=/etc

Die Bedeutung der configure Optionen:

• -default: Veranlasst das configure Skript, eine sorgfältige Auswahl an Standardwerten zu selektieren. Zum Beispiel: Nur englische Manpages, keine Nachrichtenkataloge, man ohne suid Bit, Unterstützung komprimierter Manpages, komprimieren von cat Seiten, erstellen von cat Seiten wenn das zugehörige Verzeichnis existiert, FHS Konformität duch ablegen der cat Seiten unter /var/cache/man sofern das Verzeichnis existiert.

• -confdir=/etc: Durch diese Option sucht das man Programm seine Konfigurationsdatei man.conf im /etc Verzeichnis.

Kompilieren sie das Paket: