FAQ

Si, lors de la construction de votre système LFS, vous rencontrez des erreurs, si vous vous posez des questions ou si vous pensez avoir trouvé une erreur dans le livre, merci de consulter en premier lieu la FAQ (Foire Aux Questions) sur http://www.linuxfromscratch.org/faq/.

IRC

Plusieurs membres de la communauté LFS offrent leur aide sur le serveur IRC de la communauté. Avant d'utiliser ce type d'aide, nous vous demandons d'avoir au moins vérifié la FAQ LFS et les archives des listes de diffusion pour une réponse à votre question. Vous trouverez le serveur IRC sur irc.linuxfromscratch.org port 6667. Le canal d'aide est nommé #LFS-support.

Listes de diffusion

Le serveur linuxfromscratch.org est l'hôte d'un certain nombre de listes de diffusion utilisées pour le développement du projet LFS. Ces listes incluent, entre autres, les listes principales de développement et de support.

Pour plus d'informations concernant les listes disponibles, la façon d'y souscrire, l'emplacement des archives, jetez un oeil sur http://www.linuxfromscratch.org/mail.html

Serveur News

Toutes les listes de diffusion hébergées par linuxfromscratch.org sont aussi accessibles via le serveur NNTP. Tous les messages postés sur la liste de diffusion sont copiés vers le newsgroup correspondant, et vice versa.

Le serveur news peut être accédé par news.linuxfromscratch.org.

Sites miroirs

Le projet LFS dispose de plusieurs miroirs configurés dans le monde pour vous permettre plus facilement et d'une façon plus confortable de vous y connecter et d'y télécharger les packages requis. Visitez le site http://www.linuxfromscratch.org pour la liste des miroirs actuels.

Contacts et informations

Envoyez de préférence tous vos emails vers l'une des listes de diffusion. Voir la section intitulée Listes de diffusion pour plus d'informations sur les listes de diffusion disponibles.

Mais si vous avez besoin de joindre Gerard Beekmans personnellement, envoyez un email à gerard@linuxfromscratch.org.

Membres actuels de l'équipe du projet

• Gerard Beekmans <gerard@linuxfromscratch.org> -- Initiateur du projet Linux-From-Scratch, Organisation du projet LFS.

• Matthew Burgess <matthew@linuxfromscratch.org> -- Mainteneur des packages généraux de LFS, éditeur du livre LFS.

• Craig Colton <meerkats@bellsouth.net> -- Créateur des logos des projets LFS, ALFS, BLFS et Hints.

• Jeroen Coumans <jeroen@linuxfromscratch.org> -- développeur du site web et mainteneur de la FAQ.

• Bruce Dubbs <bdubbs@linuxfromscratch.org> -- Chef de l'équipe d'assurance qualité, éditeur du livre BLFS.

• Alex Groenewoud <alex@linuxfromscratch.org> -- Editeur du livre LFS.

• Mark Hymers <markh@linuxfromscratch.org> -- Mainteneur du CVS, créateur du livre BLFS, ancien éditeur du livre LFS.

• James Iwanek <iwanek@linuxfromscratch.org> -- Membre de l'équipe de l'administration système.

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

• Anderson Lizardo <lizardo@linuxfromscratch.org> -- Créateur et mainteneur des scripts du moteur du site web.

• Bill Maltby <bill@linuxfromscratch.org> -- Organisation du projet LFS.

• Scot Mc Pherson <scot@linuxfromscratch.org> -- Mainteneur de la passerelle NNTP de LFS.

• Ryan Oliver <ryan@linuxfromscratch.org> -- Responsable de l'équipe de test, co-créateur de PLFS.

• James Robertson <jwrober@linuxfromscratch.org> -- Mainteneur de Bugzilla, développeur du Wiki, éditeur du livre BLFS.

• Greg Schafer <greg@linuxfromscratch.org> -- Mainteneur de l'ensemble des outils, éditeur du livre LFS, co-créateur de PLFS.

• Tushar Teredesai <tushar@linuxfromscratch.org> -- Editeur du livre BLFS, Mainteneur des projets Hints (astuces LFS) et Patches (correctifs).

• Jeremy Utley <jeremy@linuxfromscratch.org> -- Editeur du livre LFS, mainteneur Bugzilla.

• Un nombre incroyable d'autres personnes sur les différentes listes de diffusion LFS et BLFS qui ont rendu ce livre possible en apportant leurs suggestions, en testant le livre et en soumettant des rapports de bugs, leurs instructions et leurs expériences pour l'installation des différents packages.

Traducteurs

• Manuel Canales Esparcia <macana@lfs-es.org> -- Projet de traduction espagnol pour LFS.

• Johan Lenglet <johan@linuxfromscratch.org> -- Projet de traduction français pour LFS.

• Anderson Lizardo <lizardo@linuxfromscratch.org> -- Projet de traduction portugais pour LFS.

Mainteneurs des miroirs

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• Dag Stenstad <dag@stenstad.net> pour avoir apporté no.linuxfromscratch.org et Ian Chilton pour l'avoir fait fonctionner.

• doc.cs.univ- paris8.fr <archive@doc.cs.univ-paris8.fr> -- miroir www2.fr.linuxfromscratch.org.

• Jesse Tie-Ten- Quee <highos@linuxfromscratch.org> pour l'apport et le maintien du serveur linuxfromscratch.org.

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

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

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

Donateurs

• Dean Benson <dean@vipersoft.co.uk> pour différentes contributions monétaires.

• DREAMWVR.COM pour leur support en tant que sponsor en donnant différentes ressources pour LFS et ses sous-projets.

• Hagen Herrschaft <hrx@hrxnet.de> pour le don d'un système P4 2,2 Ghz, fonctionnant actuellement sous le nom de lorien.

• O'Reilly pour le don de livres sur SQL et PHP.

• VA Software qui, en plus de Linux.com, a donné une station de travail VA Linux 420 (ancien StartX SP2).

• Mark Stone pour avoir donné shadowfax, le premier serveur linuxfromscratch.org, un P3 750 MHz avec 512 Mo de RAM et deux disques SCSI de 9 Go. Lorsque le serveur a été déplacé, il a été renommé belgarath.

• Jesse Tie-Ten- Quee <highos@linuxfromscratch.org> pour son don d'un graveur de CDRW Yamaha 8824E.

• Un nombre incroyable de personnes sur les différentes listes de diffusion LFS qui ont rendu ce livre possible en apportant leurs suggestions, en testant le livre et en soumettant des rapports de bugs.

Anciens membres de l'équipe et contributeurs

• Timothy Bauscher <timothy@linuxfromscratch.org> -- Editeur du livre LFS, Mainteneur du projet Hints (astuces).

• Robert Briggs pour avoir donné au tout début les noms de domaine linuxfromscratch.org et linuxfromscratch.com.

• Ian Chilton <ian@ichilton.co.uk> pour maintenir le projet Hints

• Marc Heerdink <gimli@linuxfromscratch.org> -- Editeur du livre LFS.

• Seth W. Klein <sklein@linuxfromscratch.org> -- Créateur de la FAQ LFS.

• Garrett LeSage <garrett@linuxart.com> -- Créateur de la bannière originale de LFS.

• Simon Perreault <nomis80@videotron.ca> -- Mainteneur du projet Hints.

• Geert Poels <Geert.Poels@skynet.be> -- Créateur de la bannière originale de BLFS; basée sur la bannière pour LFS par Garrett LeSage.

• Frank Skettino <bkenoah@oswd.org> pour la conception initiale de l'ancien site web -- jetez un oeil sur OSWD.

• Jesse Tie-Ten- Quee <highos@linuxfromscratch.org> pour avoir répondu à un nombre impressionnant de questions sur IRC et pour avoir une grande patience.

Informations de base

A part une brève explication de votre problème, les informations essentielles à inclure dans votre requête sont :

• la version du livre que vous utilisez, c'est-à-dire 5.0,

• la distribution de l'hôte et la version à partir de laquelle vous allez créer LFS,

• avec quel package ou section vous avez un problème,

• quel est le message d'erreur exact, ou quel est le symptôme,

• si vous vous êtes éloigné du livre ou non.

(Notez que dire que vous vous êtes éloigné du livre ne signifie pas que nous ne vous aiderons pas. Après tout, LFS est justement un ensemble de choix. Cela nous aidera simplement à voir les autres causes possibles à votre problème.)

Problèmes de configuration

Quand quelque chose se passe mal pendant l'étape où le script configure est lancé, regardez dans tout le fichier config.log. Il contient les erreurs possibles qui ont été rencontrées pendant la phase de configuration, et qui ne sont pas toujours affichées à l'écran. Incluez les lignes appropriées si vous décidez de demander de l'aide.

Problèmes de compilation

Pour nous aider à trouver la cause du problème, à la fois les textes affichés à l'écran et le contenu de plusieurs fichiers sont utiles. Les informations affichées à la fois par le script ./configure et la commande make peuvent être utiles. N'incluez pas aveuglément l'ensemble, mais d'un autre côté n'en donnez pas trop peu. A titre d'exemple, voici l'affichage d'une commande make :

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

Dans ce genre de cas, nombreuses sont les personnes qui ne fournissent que la section du bas contenant le texte

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

jusqu'en bas. Cela n'est pas suffisant pour émettre un diagnostic sur le problème, car cela nous signale que quelque chose s'est mal passé, mais pas ce qui s'est mal passé. La section complète, comme fournie ci-dessus, constitue ce qui doit être inclus pour nous être utile, car il inclut la commande qui a été exécutée avec son message d'erreur.

Un excellent article sur la façon de demander de l'aide sur Internet en général a été écrit par Eric S. Raymond. Il est disponible en ligne à l'adresse http://catb.org/~esr/faqs/smart-questions.html. Lisez et suivez les astuces indiquées dans ce document et vous aurez plus de chances de recevoir une réponse pour commencer mais aussi d'avoir l'aide dont vous avez actuellement besoin.

Problèmes de la suite de tests

Beaucoup de packages disposent d'une suite de tests que, suivant l'importance du package, nous vous encourageons à lancer. Quelquefois, des packages vont générer des échecs faux ou prévus. Si vous les rencontrez, vous pouvez vérifier la page Wiki de LFS à http://wiki.linuxfromscratch.org./ si nous sommes déjà en train de travailler dessus. Si nous les connaissons déjà, alors il n'est généralement pas nécessaire de se sentir concerné.

Notes sur l'édition de liens statiques

La plupart des programmes doivent réaliser, en plus de leur tâches spécifiques, beaucoup d'opérations communes et quelques fois triviales. Cela inclut l'allocation de mémoire, la recherche dans des répertoires, la lecture et l'écriture de fichiers, la gestion de chaînes de caractères, la correspondance de modèles, l'arithmétique et bien d'autres tâches. Au lieu d'obliger tout programme à réinventer la roue, le système GNU apporte toutes les fonctions de base dans des bibliothèques toutes prêtes. La bibliothèque principale sur tout système Linux est Glibc.

Il existe principalement deux façons de lier les fonctions d'une bibliothèque à un programme qui les utilise : statiquement ou dynamiquement. Quand un programme est lié statiquement, le code des fonctions utilisées est inclut dans l'exécutable, générant ainsi un programme lourd. Lorsqu'un programme est lié dynamiquement, ce qui est inclu est une référence de l'éditeur de liens, du nom de la bibliothèque et du nom de la fonction, résultant en un exécutable bien plus petit. (Une troisième façon est d'utiliser l'interface de programmation de l'éditeur de liens. Voir la page man dlopen pour plus d'informations.)

L'édition de liens dynamiques est réalisée par défaut sur Linux et a trois avantages majeurs sur l'édition de liens statiques. Tout d'abord, vous n'avez besoin que d'une copie du code de la bibliothèque exécutable sur votre disque dur au lieu d'avoir plusieurs copies du même code inclut dans un grand nombre de programmes, donc en sauvant de l'espace disque. Deuxièmement, quand plusieurs programmes utilisent la même fonction d'une bibliothèque en même temps, seule une copie de la fonction de la bibliothèque est requise dans le coeur, ce qui sauve de l'espace mémoire. Enfin, quand une bibliothèque de fonction est déboguée ou améliorée, vous n'avez besoin que de recompiler cette bibliothèque, au lieu d'avoir à recompiler tous les programmes utilisant la fonction améliorée.

Si l'édition de liens a plusieurs avantages, alors pourquoi lier statiquement les deux premiers packages de ce chapitre ? Il existe trois raisons : historique, éducationnel et technique. Historique parce que les anciennes versions de LFS liaient statiquement tous les programmes de ce chapitre. Educationnel parce que connaître la différence est utile. Technique parce que nous gagnons un élément d'indépendance sur l'hôte. Néanmoins, il est bon de rappeler qu'une construction complète et réussie de LFS peut toujours s'achever lorsque les deux premiers packages sont liés dynamiquement.

Contenu de Binutils

Binutils est une collection d'outils de développement de logiciels contenant un éditeur de liens, un assembleur et d'autres outils pour travailler avec des fichiers objet et des archives.

Programmes installés : addr2line, ar, as, c++filt, gprof, ld, nm, objcopy, objdump, ranlib, readelf, size, strings et strip

Bibliothèques installés : libiberty.a, libbfd.[a,so] et libopcodes.[a,so]

Dépendances d'installation de Binutils

Binutils dépend de Bash, Coreutils, Diffutils, GCC, Gettext, Glibc, Grep, Make, Perl, Sed, Texinfo.

Installation de Binutils

Il est important que Binutils soit le premier package à être compilé parce que à la fois Glibc et GCC réalisent différents tests sur l'éditeur de liens et l'assembleur disponibles pour déterminer leur propres fonctionnalités à activer.

Ce package est connu pour mal se comporter si vous changez les options d'optimisation par défaut (en incluant les options -march et -mcpu). Donc, si vous avez défini des variables d'environnement qui surchargent les optimisations pas défaut, telles que CFLAGS et CXXFLAGS, nous vous recommandons de supprimer cette initialisation lors de la construction de Binutils.

La documentation de Binutils recommande de construire Binutils en dehors du répertoire des sources, c'est-à-dire dans un répertoire de construction dédié :

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

Maintenant, préparez la compilation de Binutils :

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

La signification des options de configure est :

• --prefix=/tools : Ceci indique au script configure de se préparer à installer les programmes Binutils dans le répertoire /tools.

• --disable-nls : Ceci désactive l'internationalisation (un mot généralement abrégé en i18n). Nous n'en avons pas besoin pour nos programmes statiques et nls cause souvent des problèmes lors d'une édition des liens en statique.

Continuez avec la compilation du package :

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

La signification des paramètres de make est :

• configure-host : Ceci force tous les sous-répertoires à être immédiatement configurés. Une construction statique échouera sans ça. Nous utilisons donc cette option pour contourner le problème.

• LDFLAGS="-all-static" : Ceci indique à l'éditeur de liens que tous les programmes Binutils devraient être liés statiquement. Néanmoins, en étant strict, "-all-static" est tout d'abord passé au programme libtool qui passe ensuite "-static" à l'éditeur de liens.

Enfin, installez le package :

make install

Maintenant, préparez l'éditeur de liens pour le "verrouillage" de Glibc un peu plus tard :

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

La signification des paramètres de make est :

• -C ld clean : Ceci indique au programme make de supprimer tous les fichiers compilés mais seulement dans le répertoire ld.

• -C ld LDFLAGS="-all-static" LIB_PATH=/tools/lib : Cette option reconstruit tout ce qui se trouve dans le sous-répertoire ld. Spécifier la variable makefile LIB_PATH en ligne de commande nous autorise à écraser la valeur par défaut et à la faire pointer vers notre emplacement temporaire des outils. La valeur de cette variable spécifie le chemin de recherche des bibliothèques par défaut pour l'éditeur de liens. Vous verrez comment cette préparation est ensuite utilisée dans le chapitre.

Contenu de GCC

Le package GCC contient le compilateur GNU, incluant les compilateurs C et C++.

Programmes installés : c++, cc (lien vers gcc), cc1, cc1plus, collect2, cpp, g++, gcc, gccbug et gcov

Bibliothèques installées : libgcc.a, libgcc_eh.a, libgcc_s.so, libstdc++.[a,so] et libsupc++.a

Dépendances d'installation de GCC

GCC dépend de Bash, Binutils, Coreutils, Diffutils, Findutils, Gawk, Gettext, Glibc, Grep, Make, Perl, Sed, Texinfo.

Installation de GCC

Déballez seulement l'archive tar GCC-core, car nous n'allons pas avoir besoin d'un compilateur C++ pour l'instant.

Ce package est connu pour mal se comporter si vous changez les options d'optimisation par défaut (en incluant les options -march et -mcpu). Donc, si vous avez défini des variables d'environnement qui surchargent les optimisations pas défaut, telles que CFLAGS et CXXFLAGS, nous vous recommandons de supprimer cette initialisation lors de la construction de GCC.

La documentation de GCC recommande de ne pas construire GCC dans le répertoire des sources mais dans un répertoire de construction dédié :

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

Préparez la compilation de GCC :

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

La signification des options de configure est :

• --with-local-prefix=/tools : Le but de cette option est de supprimer /usr/local/include du chemin de recherche des fichiers include de gcc. Ce n'est pas absolument essentiel ; néanmoins, vous voulons minimiser l'influence du système hôte, et ceci nous semble un point intéressant à faire dans ce but.

• --enable-shared : Cette option peut ne pas sembler intuitive au début. Mais en l'utilisant, elle permet la construction de libgcc_s.so.1 et libgcc_eh.a, et disposer de libgcc_eh.a nous assure que le script configure de Glibc (le prochain package à compiler) produira de bons résultats. Notez que les binaires gcc seront toujours liés statiquement, car ceci est contrôlé par la valeur -static de BOOT_LDFLAGS.

• --enable-languages=c : Cette option nous assure que seul le compilateur C sera construit. Cette option n'est nécessaire que si vous avez téléchargé et déballé l'archive tar GCC complète.

Continue avec la compilation du package :

make BOOT_LDFLAGS="-static" bootstrap

La signification des paramètres de make est :

• BOOT_LDFLAGS="-static" : Ceci indique à GCC de lier ses programmes statiquement.

• bootstrap : Cette cible ne compile pas GCC une seule fois mais plusieurs fois. Il utilise les programmes compilés dans le premier tour pour se compiler une deuxième fois, puis une troisième fois. Il compare alors les deuxième et troisième compilation pour s'assurer qu'il arrive à se reproduire lui-même sans fautes, ce qui semble vouloir dire qu'il a été compilé correctement.

Enfin, installez le package :

make install

En touche finale, nous créons le lien symbolique /tools/bin/cc. Beaucoup de programmes et de scripts lancent cc au lieu de gcc, ceci pour conserver des programmes génériques et donc utilisables sur tout type de système Unix. Tout le monde n'a pas le compilateur GNU C installé. Utiliser cc permet à l'administrateur système de choisir le compilateur C à installer, tant qu'un lien symbolique est créé :

ln -sf gcc /tools/bin/cc

Contenu de Linux

Le noyau Linux kernel est au coeur de chaque système Linux. C'est ce qui fait tourner Linux. Lorsqu'un ordinateur est allumé et lance un système Linux, la première pièce de logiciel Linux à être chargé est le noyau. Celui-ci initialise les composants matériels du système: ports séries, ports parallèles, cartes son, cartes réseaux, contrôleurs IDE, contrôleurs SCSI et beaucoup plus encore. EN bref, le noyau rend le matériel disponible aux logiciels exécutés.

Fichiers installés : le noyau et ses en-têtes.

Dépendances d'installation de Linux

Linux dépend de Bash, Binutils, Coreutils, Findutils, GCC, Glibc, Grep, Gzip, Make, Modutils, Perl, Sed.

Installation des en-têtes du noyau

Comme certains packages ont besoin de se référer aux fichiers d'en-tête du noyau, nous allons déballer l'archive du noyau maintenant, les configurer et copier les fichiers requis à un endroit où gcc pourra les trouver plus tard.

Préparez l'installation des en-têtes avec :

make mrproper

Ceci nous assure que le répertoire du noyau est totalement propre. L'équipe du noyau recommande que cette commande soit exécutée à chaque compilation du noyau. Vous ne devriez pas vous reposer sur un répertoire non nettoyé après le déballage.

Créez le fichier include/linux/version.h :

make include/linux/version.h

Créez le lien symbolique spécifique à la platforme include/asm :

make symlinks

Installez les fichiers d'en-têtes spécifiques à la platforme :

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

Installez les autres fichiers d'en-têtes du noyau :

cp -R include/linux /tools/include

Il existe quelques fichiers d'en-têtes du noyau utilisant le fichier autoconf.h. Comme nous ne configurons pas encore le noyau, nous avons besoin de créer ce fichier nous-même pour éviter les erreurs de compilation. Créez un fichier autoconf.h vide :

touch /tools/include/linux/autoconf.h

Contenu de Glibc

(Dernière vérification effectuée auprès de la version 2.3.2.)

Glibc est une bibliothèque C qui apporte les appels système et les fonctions de base telles que open, malloc, printf, etc. La bibliothèque C est utilisée par tous les programmes liés dynamiquement.

Programmes installés : 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 et zic

Bibliothèques installées : 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 et libutil.[a,so]

Dépendances d'installation de Glibc

Glibc dépend de Bash, Binutils, Coreutils, Diffutils, Gawk, GCC, Gettext, Grep, Make, Perl, Sed, Texinfo.

Installation de Glibc

Avant de commencer l'installation de la Glibc, vous devez entrer (cd) dans le répertoire glibc-2.3.2 et déballer Glibc-linuxthreads dans ce répertoire, et non pas dans le répertoire où vous déballez habituellement tous les sources.

Ce package est connu pour mal se comporter si vous changez les options d'optimisation par défaut (en incluant les options -march et -mcpu). Donc, si vous avez défini des variables d'environnement qui surchargent les optimisations pas défaut, telles que CFLAGS et CXXFLAGS, nous vous recommandons de supprimer cette initialisation lors de la construction de Glibc.

Basiquement, compiler Glibc de tout autre façon que celle proposée par le livre compromet la stabilité de votre système.

Bien qu'il s'agisse d'un message sans gravité, l'étape d'installation de Glibc se plaindra de l'absence de /tools/etc/ld.so.conf. Corrigez ce petit message ennuyant avec :

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

De même, Glibc a un problème subtil s'il est compilé avec GCC 3.3.1. Appliquez le correctif suivant pour corriger ceci :

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

La documentation de Glibc recommande de construire Glibc en dehors du répertoire des sources, c'est-à-dire dans un répertoire dédié :

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

Ensuite, préparez la compilation de Glibc :

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

La signification des options de configure est :

• --disable-profile : Ceci désactive la construction des bibliothèques avec les informations de profilage. Enlevez cette option si vous pensez faire du profilage.

• --enable-add-ons : Ceci active tous les composants supplémentaires (add-ons) installés avec Glibc, dans notre cas Linuxthreads.

• --with-binutils=/tools/bin et --with-headers=/tools/include : Ces options ne sont pas réellement nécessaires. Mais elles nous assurent que rien de mauvais ne peut arriver en ce qui concerne les en-têtes du noyau et que les programmes Binutils sont utilisés lors de la construction de Glibc.

• --without-gd : Cette option nous assure que le programme memusagestat ne sera pas construit, car de façon assez étrange celui-ci insiste pour être lié avec les bibliothèques de l'hôte (libgd, libpng, libz et ainsi de suite).

Lors de cette étape, vous rencontrerez peut-être le message suivant :

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

Le programme msgfmt, manquant ou incompatible, ne pose généralement pas de problème mais certaines personnes pensent qu'il peut poser problème lors de l'exécution de la suite de tests.

Compilez le package :

make

Lancez la suite de tests :

make check

La suite de tests de Glibc est grandement dépendante de certaines fonctionnalités de votre système hôte, en particulier du noyau. De plus, dans ce chapitre, certains tests peuvent être affecter durement par les outils existants ainsi que par des problèmes d'environnement sur le système hôte. Bien sûr, ceci ne sera plus un problème lorsque nous lançerons la suite de tests de Glibc dans l'environnement chroot au cours du chapitre 6. En général, la suite de tests de Glibc réussit. Néanmoins, comme mentionné ci-dessus, quelques échecs sont inévitables sous certaines circonstances. Voici une liste des problèmes les plus communs que nous connaissons :

• Le test math échoue parfois lorsqu'il est exécuté sur des systèmes où le processeur n'est pas un nouveau Intel ou AMD. Certains paramètrages d'optimisation sont aussi connus pour être la source de ce type de problèmes.

• Le test gettext échoue quelque fois à cause de problèmes sur le système hôte. Les raisons exactes ne sont pas encore claires.

• Le test atime échoue quelque fois lorsque la partition LFS est montée avec l'option noatime ou à cause d'autres spécificités des autres systèmes de fichiers.

• Le test shm pourrait échouer si le système hôte utilise le système de fichiers devfs mais ne dispose pas du système de fichiers tmpfs monté sur /dev/shm à cause d'un manque de support de tmpfs dans le noyau.

• En cas d'exécution sur d'anciens matériels (lents), certains tests pourraient échouer à cause de limite de temps dépassée.

En résumé, ne vous inquiétez pas trop si vous voyez des échecs lors des tests de la Glibc dans ce chapitre. La Glibc au chapitre 6 est celle avec qui nous allons rester, donc c'est celle-ci pour qui les tests doivent réussir. Mais gardez en tête, y compris au chapitre 6 que certaines erreurs peuvent arriver, les tests de math par exemple. Si vous essuyez un échec, notez-le puis essayez de relancer make check. La suite de tests devrait reprendre là où elle s'était arrêtée. Vous pouvez passer cette séquence arrêt-relancement en lançant un make -k check. Mais en faisant cela, assurez-vous de sauvegarder la sortie pour que vous puissiez examiner les traces plus tard et savoir ainsi le nombre total d'échecs.

Maintenant, installez le package :

make install

Différents pays et cultures ont des conventions variables sur la façon de communiquer. Ces conventions vont du très simple, telle que la représentation de la date et de l'heure à du très compliqué, telle que le langage parlé. L'internationalisation des programmes GNU fonctionne en utilisant les locales. Nous installons les locales Glibc maintenant :

make localedata/install-locales

Une alternative au lancement de la commande précédente est d'installer uniquement les locales dont vous avez besoin ou que vous souhaitez. Ceci est possible en utilisant la commande localedef. Des informations sur cette commande sont disponibles dans le fichier INSTALL des sources glibc-2.3.2. Néanmoins, il existe un certain nombre de locales essentielles pour réussir les tests des futurs packages, en particulier les tests de libstdc++ provenant de GCC. Les instructions suivantes, au lieu de la cible install-locales comme ci-dessus, installent l'ensemble minimum de locales nécessaires à la bonne réussite des tests :

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

Contenu de Tcl

(Dernière vérification effectuée auprès de la version 8.4.4.)

Le package Tcl contient le langage de commandes outils (Tool Command Language).

Tcl installe les fichiers suivants:

Programmes installés : tclsh (lien vers tclsh8.4), tclsh8.4

Bibliothèque installée : libtcl8.4.so

Dépendances d'installation de Tcl

Tcl dépend de Bash, Binutils, Coreutils, Diffutils, GCC, Glibc, Grep, Make, Sed.

Installation de Tcl

Ce package et les deux suivants sont seulement installés dans le but de lancer les suites de tests pour GCC et Binutils. Installer ces trois packages juste pour des tests peut sembler beaucoup mais il est très rassurant, voire essentiel, de savoir que nos outils les plus importants fonctionnent correctement.

Préparez la compilation de Tcl :

cd unix
./configure --prefix=/tools

Construisez le package :

make

Ce package dispose d'une suite de tests pouvant réaliser un certain nombre de vérification pour nous assurer que tout est construit correctement. Néanmoins, la suite de tests Tcl dans ce chapitre est connu pour ses échecs sous certaines conditions dépendant de l'hôte et qui ne sont pas totalement comprises. Du coup, ces échecs ne sont pas surprenant et ne doivent pas être considérés comme critiques. Si vous souhaitez lancer le suite de tests, la commande suivante le fera :

TZ=UTC make test

La signification du paramètre de make est :

• TZ=UTC : Ceci initialise la zone horaire à l'UTC (Coordinated Universal Time) aussi connue comme GMT (Greenwich Mean Time), mais seulement pendant la durée de cette suite de tests. Ceci nous assure que les tests concernant l'horloge seront réalisés correctement. Plus d'informations sur la variable d'environnement TZ seront disponibles plus tard sur chapitre 7.

Quelque fois, les suites de tests des packages échouent pour des raisons erronées. Vous pouvez consulter le Wiki LFS sur http://wiki.linuxfromscratch.org/ pour vérifier si ces échecs sont normaux. Ceci s'applique à tous les tests du livre.

Installez le package :

make install

Créez le lien symbolique nécessaire :

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

Contenu de Expect

Le package Expect contient un programme exécutant un dialogue programmé avec d'autres programmes interactifs.

Programme installé : expect

Bibliothèque installée : libexpect5.39.a

Dépendances d'installation d'Expect

Expect dépend de Bash, Binutils, Coreutils, Diffutils, GCC, Glibc, Grep, Make, Sed, Tcl.

Installation of Expect

First apply a patch:

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

This fixes a bug in Expect that can result in bogus failures during the GCC test suite run.

Now prepare Expect for compilation:

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

The meaning of the configure options:

• --with-tcl=/tools/lib: This ensures that the configure script finds the Tcl installation in our temporary tools location. We don't want it to find an existing one that may possibly reside on the host system.

• --with-x=no: This tells the configure script not to search for Tk (the Tcl GUI component) or the X Window System libraries, both of which may possibly reside on the host system.

Build the package:

make

This package has a test suite available which can perform a number of checks to ensure it built correctly. However, the Expect test suite here in Chapter 5 is known to experience failures under certain host conditions that are not fully understood. Therefore, test suite failures here are not surprising, but are not considered critical. Should you choose to run the test suite, the following command will do so:

make test

And install:

make SCRIPTS="" install

The meaning of the make parameter:

• SCRIPTS="": This prevents installation of the supplementary expect scripts which are not needed.

You can now remove the source directories of both Tcl and Expect.

Contenu de DejaGnu

Le package DejaGnu contient un groupe de travail pour tester d'autres programmes.

Programme installé : runtest

Dépendances d'installation de DejaGnu

Dejagnu dépend de Bash, Binutils, Coreutils, Diffutils, GCC, Glibc, Grep, Make, Sed.

Installation de DejaGnu

Préparez la compilation de DejaGnu :

./configure --prefix=/tools

Construisez et installez le package :

make install

Réinstallation de GCC

Les outils requis pour tester GCC et Binutils sont maintenant installés (Tcl, Expect et DejaGnu). Nous pouvons continuer en reconstruisant GCC et Binutils, en les liant avec la nouvelle Glibc et en les testant correctement. Une chose à noter, néanmoins, est que ces suites de tests dépendent énormément de pseudos terminaux (PTY) fonctionnels fournis par votre distribution hôte. Actuellement, les PTY sont souvent implémentés via le système de fichiers devpts. Vous pouvez rapidement vérifier si votre système hôte est correctement configuré en cela en réalisant un simple test :

expect -c "spawn ls"

Si vous obtenez le message :

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

Votre distribution hôte n'est pas correctement configurée pour les PTY. Dans ce cas, il ne sert à rien de lancer les suites de tests de GCC et Binutils jusqu'à la correction de ce problème. Vous pouvez consulter le Wiki LFS sur http://wiki.linuxfromscratch.org/ pour plus d'informations pour faire fonctionner les PTY.

Déballez les trois archives tar de GCC (-core, -g++ et -testsuite) dans un seul répertoire. Elles se placeront dans un seul sous-répertoire gcc-3.3.1/.

Tout d'abord, corrigez un problème et faites un ajustement essentiel :

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

Le premier correctif désactive le script GCC "fixincludes". Nous l'avions mentionné brièvement mais une explication plus en détail de fixincludes est apportée ici. Sous des circonstances normales, le script GCC fixincludes parcourt votre système pour trouver les fichiers d'en-tête qui ont besoin d'être corrigés. Il pourrait trouver que certains des fichiers d'en-têtes de Glibc sur votre système devraient être corrigés, les corriger et les placer dans le répertoire des en-têtes privés de GCC. Plus tard dans le chapitre 6, après avoir installé la nouvelle Glibc, ce répertoire serait recherché avant le répertoire include du système, faisant que GCC trouverait les en-têtes corrigés du système hôte qui ne correspondraient certainement pas à la version de Glibc actuellement utilisée pour le système LFS.

Le dernier correctif modifie l'emplacement par défaut de l'éditeur de liens dynamiques de GCC (généralement ld-linux.so.2). il supprime aussi /usr/include du chemin de recherche des includes de GCC. Corriger cela maintenant plutôt qu'ajuster le fichier specs après l'installation nous assure que notre éditeur de liens dynamiques sera utilisé lors de la construction de GCC. C'est-à-dire que tous les binaires finaux (et temporaires) créés lors de la construction seront liés à la nouvelle Glibc.

Créez un répertoire de construction séparé de nouveau :

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

Avant de commencer la construction de GCC, rappelez de désinitialiser toute variable d'environnement pour surcharger les options d'optimisation par défaut.

Maintenant, préparez la compilation de GCC :

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

La signification des nouvelles options de configure est :

• --enable-threads=posix : Ceci active la gestion des exceptions C++ pour le code multi-threadé.

• --enable-__cxa_atexit : Cette option autorise l'utilisation de __cxa_atexit, plutôt que atexit, pour enregistrer les destructeurs C++ destructors des objets statiques locales et globales et est essentiel pour la gestion des destructeurs en compatibilité complète avec les standards. Il affecte aussi l'ABI C++ et donc résulte en des bibliothèques partagées et des programmes C++ interopérables avec les autres distributions Linux.

• --enable-clocale=gnu : Cette option nous assure que le bon modèle de locale est sélectionné pour les bibliothèques C++ sous toutes les circonstances. Si le script configure trouve la locale de_DE installée, il sélectionnera le bon modèle de gnu. Néanmoins, les personnes qui n'installent pas la locale de_DE courent le risque de construire les bibliothèques C++ incompatibles avec ABI dû au mauvais modèle de locale, generic, sélectionné.

• --enable-languages=c,c++ : Cette option est nécessaire pour s'assurer que les compilateurs C et C++ sont construits.

Compilez le package :

make

Il n'est pas nécessaire d'utiliser la cible bootstrap maintenant car le compilateur que nous utilisons pour compiler ce GCC a été construit avec exactement la même version des sources de GCC utilisées précédemment.

Testez le résultat :

make -k check

L'option -k est utilisée pour faire en sorte que toute la suite de tests soit exécutée et ne s'arrête pas au premier échec. La suite de tests GCC est très complète et il est pratiquement garanti que certaines erreurs apparaîtront. Pour obtenir un résumé des résultats de la suite de tests, lancez ceci :

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

Vous pouvez comparer vos résultats avec ceux postés sur la liste de diffusion gcc-testresults pour des configurations similaires à la vôtre. Pour un exemple concernant la version actuelle GCC-3.3.1 sur un i686-pc-linux-gnu, voir http://gcc.gnu.org/ml/gcc-testresults/2003-08/msg01612.html.

Notez que les résultats contiennent :

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

La partie échouée ("unexpected pass") pour g++ est dûe à l'utilisation de --enable-__cxa_atexit. Apparemment, toutes les plateformes supportées par GCC ne disposent pas du support de "__cxa_atexit" dans leur bibliothèques C, donc il est probable que ce test ne réussira pas.

Les 26 parties échouées pour libstdc++ sont dues à l'utilisation de --enable-clocale=gnu, qui est le choix correct pour des systèmes basées sur Glibc, versions 2.2.5 et supérieurs. Le support de la locale dans la bibliothèque GNU C est supérieurà l'autre modèle sélectionné ("generic") qui pourrait être applicable si par exemple vous utilisiez Newlibc, Sun-libc ou tout autre libc). La suite de tests libstdc++ attend apparemment le modèle "generic", donc ces tests ne passent pas obligatoirement.

Des échecs inattendues ne peuvent souvent pas être évités. Les développeurs GCC sont habituellement au courant mais n'ont pas encore réussi à les corriger. En bref, sauf si vos résultats sont grandement différents de ceux présents sur l'URL ci-dessus, il est sain de continuer.

Et finalement, installez le package :

make install

Ré-installation de Binutils

Créez de nouveau un répertoire de construction séparé :

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

Maintenant, préparez la compilation de Binutils :

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

La signification des nouvelles options de configure est la suivante :

• --with-lib-path=/tools/lib: Ceci indique au script configure de spécifier le chemin de recherche par défaut des bibliothèques. Nous ne voulons pas que le chemin de recherche contienne des répertoires du système hôte.

Avant de commencer la construction de Binutils, rappellez-vous de dé-initialiser toute variable d'environnement qui surcharge les options d'optimisation par défaut.

Compilez le package :

make 

Testez le résultat (il ne devrait pas y avoir d'échecs inattendus ici, les échecs attendus sont bons) :

make check

Malheureusement, il n'existe pas de façon facile de visualiser le résumé des résultats des tests comme c'était le cas pour le précédent package GCC. Néanmoins, si un échec arrive, il devrait être facile à trouver. La sortie devrait contenir ceci :

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

Enfin, installez le package :

make install

Maintenant, préparez Binutils pour le ré-ajustement de l'ensemble des outils du chapitre suivant :

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

Contenu de Gawk

Gawk est une implémentation de awk qui est utilisée pour manipuler des fichiers texte.

Programmes installés : awk (lien vers gawk), gawk, gawk-3.1.3, grcat, igawk, pgawk, pgawk-3.1.3 et pwcat.

Dépendances d'installation de Gawk

Gawk dépend de Bash, Binutils, Coreutils, Diffutils, GCC, Gettext, Glibc, Grep, Make, Sed.

Installation de Gawk

Préparez la compilation de Gawk :

./configure --prefix=/tools

Compilez le package :

make

Ce package dispose d'une suite de tests, réalisant plusieurs tests pour s'assurer que le programme a été construit correctement. Si vous décidez de le lancer, la commande suivante fera le nécessaire :

make check

Et installez le package :

make install

Contenu de Coreutils

Le package Coreutils contient un grand ensemble d'utilitaires shell basiques.

Programmes installés : 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 et yes

Dépendances d'installation de Coreutils

Coreutils dépend de Bash, Binutils, Coreutils, Diffutils, GCC, Gettext, Glibc, Grep, Make, Perl, Sed.

Installation de Coreutils

Préparez la compilation de Coreutils :

./configure --prefix=/tools

Compilez le package :

make

Ce package dispose d'une suite de tests, réalisant plusieurs tests pour s'assurer que le programme a été construit correctement. Si vous décidez de le lancer, la commande suivante fera le nécessaire :

make RUN_EXPENSIVE_TESTS=yes check

La signification du paramètre de make est :

• RUN_EXPENSIVE_TESTS=yes : Ceci indique à la suite de tests de lancer plusieurs tests supplémentaires considérés habituellement longs sur certaines plate-formes. Néanmoins, elles ne sont généralement pas un problème sous Linux.

Et installez le package :

make install

Contenu de Bzip2

Bzip2 est un compresseur de fichiers qui arrive habituellement à une meilleure compression que ne le fait gzip traditionel.

Programmes installés : bunzip2 (lien vers bzip2), bzcat (lien vers bzip2), bzcmp, bzdiff, bzegrep, bzfgrep, bzgrep, bzip2, bzip2recover, bzless et bzmore

Bibliothèques installées : libbz2.a, libbz2.so (lien vers libbz2.so.1.0), libbz2.so.1.0 (lien vers libbz2.so.1.0.2) et libbz2.so.1.0.2

Dépendances d'installation de Bzip2

Bzip2 dépend de Bash, Binutils, Coreutils, Diffutils, GCC, Glibc, Make.

Installation de Bzip2

Le package Bzip2 ne contient pas de script configure. Compilez et installez-le ainsi :

make PREFIX=/tools install

Contenu de Gzip

Le package Gzip contient des programmes pour compresser et décompresser des fichiers utilisant le codage Lempel-Ziv (LZ77).

Programmes installés : gunzip (lien vers gzip), gzexe, gzip, uncompress (lien vers gunzip), zcat (lien vers gzip), zcmp, zdiff, zegrep, zfgrep, zforce, zgrep, zless, zmore et znew

Dépendances d'installation de Gzip

Gzip dépend de Bash, Binutils, Coreutils, Diffutils, GCC, Glibc, Grep, Make, Sed.

Installation de Gzip

Préparez la compilation de Gzip :

./configure --prefix=/tools

Compilez le package :

make

Et installez-le :

make install

Contenu de Diffutils

Les programmes de ce package vous montre les différences entre les deux fichiers ou répertoires. Son utilisation la plus commune est la création de correctifs.

Programmes installés : cmp, diff, diff3 et sdiff

Dépendances d'installation de Diffutils

Diffutils dépend de Bash, Binutils, Coreutils, Diffutils, GCC, Gettext, Glibc, Grep, Make, Sed.

Installation de Diffutils

Préparez la compilation de Diffutils :

./configure --prefix=/tools

Compilez le package :

make

Et installez-le :

make install

Contenu de Findutils

Le package Findutils contient les programmes de recherche de fichiers, soit en direct (en faisant une recherche récursive en direct à travers les répertoires et seulement en affichant des fichiers qui remplissent ses spécifications) soit en cherchant à travers une base de données.

Programmes installés : bigram, code, find, frcode, locate, updatedb et xargs

Dépendances d'installation de Findutils

Findutils dépend de Bash, Binutils, Coreutils, Diffutils, GCC, Gettext, Glibc, Grep, Make, Sed.

Installation de Findutils

Préparez la compilation de Findutils :

./configure --prefix=/tools

Compilez le package :

make 

Ce package dispose d'une suite de tests, réalisant plusieurs tests pour s'assurer que le programme a été construit correctement. Si vous décidez de le lancer, la commande suivante fera le nécessaire :

make check

Et installez le package :

make install

Contenu de Make

Make détermine, automatiquement, quelles pièces d'un grand programme ont besoin d'être recompilées et envoie les commandes pour les recompiler.

Programme installé : make

Dépendances d'installation de Make

Make dépend de Bash, Binutils, Coreutils, Diffutils, GCC, Gettext, Glibc, Grep, Sed.

Installation de Make

Préparez la compilation de Make :

./configure --prefix=/tools

Compilez le programme :

make 

Ce package dispose d'une suite de tests, réalisant plusieurs tests pour s'assurer que le programme a été construit correctement. Si vous décidez de le lancer, la commande suivante fera le nécessaire :

make check

Puis installez le package et sa documentation :

make install

Contenu de Grep

Grep est un programme utilisé pour imprimer des lignes d'un fichier ressemblant à un modèle spécifié.

Programmes installés : egrep (lien vers grep), fgrep (lien vers grep) et grep

Dépendances d'installation de Grep

Grep dépend de Bash, Binutils, Coreutils, Diffutils, GCC, Gettext, Glibc, Make, Sed, Texinfo.

Installation de Grep

Préparez la compilation de Grep :

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

La signification des options de configure est :

• --disable-perl-regexp : Ceci nous assure que grep ne sera pas lié avec une bibliothèque PCRE qui pourrait être présente sur l'hôte mais ne serait pas disponible une fois entré dans l'environnement chroot.

• --with-included-regex : Ceci nous assure que Grep utilise son code interne pour les expressions rationnelles. Sans cela, il utiliserait le code de Glibc, connu pour être légèrement bogué.

Compilez les programmes :

make 

Ce package dispose d'une suite de tests, réalisant plusieurs tests pour s'assurer que le programme a été construit correctement. Si vous décidez de le lancer, la commande suivante fera le nécessaire :

make check

Puis, installez-les ainsi que leur documentation :

make install

Contenu de Sed

sed est un éditeur en flux. Un éditeur en flux est utilisé pour réaliser des transformations de texte basique sur une entrée en flux (un fichier ou une entrée à partir d'un tuyau).

Programme installé : sed

Dépendances d'installation de Sed

(Dernière vérification effectuée auprès de la version 3.02.)

Sed dépend de Bash, Binutils, Coreutils, Diffutils, GCC, Gettext, Glibc, Grep, Make, Texinfo.

Installation de Sed

Préparez la compilation de Sed :

./configure --prefix=/tools

Compilez le programme :

make 

Ce package dispose d'une suite de tests, réalisant plusieurs tests pour s'assurer que le programme a été construit correctement. Si vous décidez de le lancer, la commande suivante fera le nécessaire :

make check

Puis, installez-le avec sa documentation :

make install

Contenu de Gettext

Le package Gettext est utilisé pour l'internationalisation et la localisation. Les programmes peuvent êtres compilés avec le support de la langue native ('Native Language Support' ou NLS) qui leur permettent d'afficher les messages dans la langue native de l'utilisateur.

Programmes installés : 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 et xgettext

Bibliothèques installées : libasprintf[a,so], libgettextlib[a,so], libgettextpo[a,so] et libgettextsrc[a,so]

Dépendances d'installation de Gettext

Gettext dépend de Bash, Binutils, Bison, Coreutils, Diffutils, Gawk, GCC, Glibc, Grep, Make, Sed.

Installation de Gettext

Préparez la compilation de Gettext :

./configure --prefix=/tools

Compilez les programmes :

make

Ce package dispose d'une suite de tests, réalisant plusieurs tests pour s'assurer que le programme a été construit correctement. Néanmoins, la suite de tests de Gettext est connu pour ses échecs lors du chapitre 5 sous certaines conditions dues à l'hôte, par exemple s'il trouve un compilateur Java sur l'hôte. La suite de tests Gettex prend un assez long moment à s'exécuter et n'est pas considérée comme étant critique. Donc, nous ne vous recommendons pas de la lancer maintenant. Si vous décidez de le faire, la commande suivante fera le nécessaire :

make check

Et installez le package :

make install

Contenu de Ncurses

(Dernière version effectuée auprès de la version 5.3.)

Le package Ncurses apporte des bibliothèques de gestion de caractères et de terminaux, incluant les panneaux et les menus.

Programmes installés : captoinfo (lien vers tic), clear, infocmp, infotocap (lien vers tic), reset (lien vers tset), tack, tic, toe, tput et tset

Bibliothèques installées : libcurses.[a,so] (lien vers libncurses.[a,so]), libform.[a,so], libmenu.[a,so], libncurses++.a, libncurses.[a,so], libpanel.[a,so]

Dépendances d'installation de Ncurses

Ncurses dépend de Bash, Binutils, Coreutils, Diffutils, Gawk, GCC, Glibc, Grep, Make, Sed.

Installation de Ncurses

Corrigez deux petits problèmes :

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

Le premier correctif prend en compte le fichier d'en-tête etip.h alors que le second empêche quelques avertissements du compilateur à cause des en-têtes obsolètes.

Maintenant, préparez la compilation de Ncurses :

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

La signification des options de configure est :

• --without-ada : Ceci indique à Ncurses de ne pas construire ses liens avec Ada, y compris si un compilateur Ada est installé sur l'hôte. Ceci est nécessaire car, lorsque nous entrerons dans l'environnement chroot, Ada ne sera plus disponible.

• --enable-overwrite : Ceci indique à Ncurses d'installer les fichiers d'en-tête dans /tools/include au lieu de /tools/include/ncurses pour s'assurer que les autres packages trouveront bien les en-têtes de Ncurses.

Compilez les programmes et les bibliothèques :

make 

Puis, installez-les avec leur documentation :

make install

Contenu de Patch

Le programme patch modifie un fichier suivant un fichier patch, appelé aussi correctif. Un correctif est habituellement une liste, créée par le programme diff, et contenant les instructions sur la façon dont le fichier original a été modifié.

Programme installé : patch

Dépendances d'installation de Patch

Patch dépend de Bash, Binutils, Coreutils, Diffutils, GCC, Glibc, Grep, Make, Sed.

Installation de Patch

Préparez la compilation de Patch :

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

L'option du préprocesseur -D_GNU_SOURCE est nécessaire uniquement pour les plateformes PowerPC. Vous pouvez l'oublier pour les autres architectures.

Compilez le programme :

make 

Puis, installez-la avec sa documentation :

make install

Contenu de Tar

Tar est un programme d'archivage permettant de stocker et d'extraire des fichiers à partir d'un fichier d'archive connu comme un fichier tar.

Programmes installés : rmt et tar

Dépendances d'installation de Tar

Tar dépend de Bash, Binutils, Coreutils, Diffutils, GCC, Gettext, Glibc, Grep, Make, Sed.

Installation de Tar

Préparez la compilation de Tar :

./configure --prefix=/tools

Compilez les programmes :

make 

Ce package dispose d'une suite de tests, réalisant plusieurs tests pour s'assurer que le programme a été construit correctement. Si vous décidez de le lancer, la commande suivante fera le nécessaire :

make check

Puis, installez-les avec leur documentation :

make install

Contenu de Texinfo

Le package Texinfo contient des programmes utilisés pour lire, écrire et convertir des documents Info, qui apporte une documentation système.

Programmes installés : info, infokey, install-info, makeinfo, texi2dvi et texindex

Dépendances d'installation de Texinfo

Texinfo dépend de Bash, Binutils, Coreutils, Diffutils, GCC, Gettext, Glibc, Grep, Make, Ncurses, Sed.

Installation de Texinfo

Préparez la compilation de Texinfo :

./configure --prefix=/tools

Compilez les programmes :

make 

Ce package dispose d'une suite de tests, réalisant plusieurs tests pour s'assurer que le programme a été construit correctement. Si vous décidez de le lancer, la commande suivante fera le nécessaire :

make check

Puis, installez-les avec leur documentation :

make install

Contenu de Bash

Bash, acronyme de Bourne-Again SHell, est un interpréteur de commande très répandu sur les systèmes Unix. Il se charge d'interpréter et d'évaluer les commandes que l'utilisateur entre sur l'entrée standard (le clavier), comme par exemple lancer un programme.

Programmes installés : bash, sh (lien vers bash) et bashbug

Dépendances d'installation de Bash

Bash dépend de Binutils, Coreutils, Diffutils, Gawk, GCC, Glibc, Grep, Make, Ncurses, Sed.

Installation de Bash

Bash contient un certain nombre de bogues connus. Corrigez-les avec les correctifs suivants :

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

Maintenant, préparez la compilation de Bash :

./configure --prefix=/tools

Compilez le programme :

make

Ce package dispose d'une suite de tests, réalisant plusieurs tests pour s'assurer que le programme a été construit correctement. Si vous décidez de le lancer, la commande suivante fera le nécessaire :

make tests

Puis, installez-le ainsi que sa documentation :

make install

Ajoutez un lien pour les programmes utilisant sh comme shell :

ln -s bash /tools/bin/sh

Contenu de Util-linux

Le package Util-linux contient un certain nombre d'utilitaires divers. Certains des plus connus d'entre eux sont utilisés pour monter, démonter, formatter, partionner et gérer des disques durs, ouvrir des ports tty ainsi que récupérer des messages du noyau.

Programmes installés : 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 (lien vers rdev), raw, rdev, readprofile, rename, renice, rev, rootflags (lien vers rdev), script, setfdprm, setsid, setterm, sfdisk, swapoff (lien vers swapon), swapon, test.bash, test.tcsh, tunelp, ul, umount, vidmode (lien vers rdev), whereis et write

Dépendances d'installation de Util-linux

Util-linux dépend de Bash, Binutils, Coreutils, Diffutils, GCC, Gettext, Glibc, Grep, Make, Ncurses, Sed, Zlib.

Installation de Util-linux

Util-linux n'utilise pas l'installation toute fraîche des headers et librairies provenant du répertoire /tools. Ceci est résolu en modifiant le script configure :

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

Préparez la compilation de Util-linux :

./configure

Compilez quelques routines d'aide :

make -C lib

Et, comme vous allez avoir besoin de quelques utilitaires contenus dans ce package, construisez uniquement ceux-ci :

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

Maintenant, copiez ces programmes dans le répertoire des outils temporaires: :

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

Contenu de Perl

Le package Perl contient perl, l'acronyme de Practical Extraction and Report Language (Langage pratique d'extraction et de rapport). Perl combine certaines des meilleurs fonctionnalités des langages C, sed, awk et sh en un seul langage extrêmement puissant.

Programmes installés : a2p, c2ph, dprofpp, enc2xs, find2perl, h2ph, h2xs, libnetcfg, perl, perl5.8.0 (lien vers perl), perlbug, perlcc, perldoc, perlivp, piconv, pl2pm, pod2html, pod2latex, pod2man, pod2text, pod2usage, podchecker, podselect, psed (lien vers s2p), pstruct (lien vers c2ph), s2p, splain and xsubpp

Bibliothèques installées : (trop nombreux pour les nommer toutes)

Dépendances d'installation de Perl

Perl dépend de Bash, Binutils, Coreutils, Diffutils, Gawk, GCC, Glibc, Grep, Make, Sed.

Installation de Perl

Tout d'abord, adaptez quelques chemins en dur de la bibliothèque C :

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

Et assurez-vous que les extensions statiques sont bien construites :

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

Maintenant, préparez la compilation de Perl :

./configure.gnu --prefix=/tools

Compilez seulement les outils requis :

make perl utilities

Puis, copiez ces outils et leur bibliothèques :

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

Remarques à propos de la conformité FHS

Nous avons basé notre arborescence de répertoires sur le standard FHS (disponible sur http://www.pathname.com/fhs/). En plus de cette arborescence, ce standard stipule l'existence de /usr/local/games et /usr/share/games, mais nous ne voyons pas l'intérêt de ceux-ci pour un système de base. Néanmoins, vous êtes libres de rendre votre système compatible FHS. En ce qui concerne la structure du sous-répertoire /usr/local/share, le FHS est inprécis, donc nous créons ici les répertoires qui nous semblent nécessaires.

Contenu de MAKEDEV

Le script MAKEDEV crée les noeuds de périphériques statiques qui résident habituellement dans le répertoire /dev. Des informations détaillées sur les noeuds périphériques puissent être trouvées dans le fichier Documentation/devices.txt dans le répertoire des sources du noyau Linux.

Script installé : MAKEDEV

Dépendances d'installation de MAKEDEV

Make dépend de Bash, Coreutils.

Créer des périphériques

Notez que déballer le fichier MAKEDEV-1.7.bz2 ne crée pas un répertoire car le fichier ne contient qu'un script shell.

Installez le script MAKEDEV :

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

Lancez le script pour créer les fichiers de périphériques :

cd /dev
./MAKEDEV -v generic-nopty

La signification des arguments est la suivante :

• -v : Ceci indique au script de se lancer en mode verbeux.

• generic-nopty : Ceci indique à MAKEDEV de créer une sélection générique des fichiers spéciaux (périphériques) utilisés habituellement, sauf pour les fichiers ptyXX et ttyXX. Nous n'avons pas besoin de ces fichiers parce que nous allons utiliser les PTY Unix98 via le système de fichiers devpts.

S'il s'avère que certains périphériques spéciaux zzz dont vous avez besoin manquent, essayez de lancer ./MAKEDEV -v zzz. Autrement, vous pourriez créer des périphériques via le programme mknod. Merci de vous référer aux pages man et info si vous avez besoin de plus d'informations.

Sinon, si vous êtes incapable de monter le système de fichiers devpts plus tôt dans la section "Monter les systèmes fichiers proc et devpts", c'est le bon moment pour essayer les alternatives. Si votre noyau supporte le système de fichiers devfs, lancez la commande suivante pour monter devfs :

mount -t devfs devfs /dev

Ceci montera le système de fichiers devfs au-dessus de la nouvelle structure statique /dev. Ceci ne pose pas de problèmes, car les noeuds du périphériques créés sont toujours présents, ils sont juste cachés par le nouveau système de fichiers devfs.

Si ceci ne fonctionne toujours pas, la seule option laissée est d'utiliser le script MAKEDEV pour créer les fichiers ptyXX et ttyXX qui ne seraient autrement pas nécessaire. Assurez-vous de bien être dans le répertoire /dev puis lancez ./MAKEDEV -v pty. Le mauvais côté de ceci est le suivant : nous allons créer 512 fichiers spéciaux supplémentaires qui ne seront pas nécessaire lorsque nous démarrerons enfin notre système LFS terminé.

Contenu de Linux

Le noyau Linux kernel est au coeur de chaque système Linux. C'est ce qui fait tourner Linux. Lorsqu'un ordinateur est allumé et lance un système Linux, la première pièce de logiciel Linux à être chargé est le noyau. Celui-ci initialise les composants matériels du système: ports séries, ports parallèles, cartes son, cartes réseaux, contrôleurs IDE, contrôleurs SCSI et beaucoup plus encore. EN bref, le noyau rend le matériel disponible aux logiciels exécutés.

Fichiers installés : le noyau et ses en-têtes.

Dépendances d'installation de Linux

Linux dépend de Bash, Binutils, Coreutils, Findutils, GCC, Glibc, Grep, Gzip, Make, Modutils, Perl, Sed.

Installation des en-têtes du noyau

Nous n'allons pas encore compiler un nouveau noyau -- nous le ferons quand nous aurons terminé l'installation de tous les paquets. Mais comme certains paquets ont besoin des fichiers d'en-têtes, nous allons déballer l'archive du noyau maintenant, le configurer et copier les fichiers d'en-têtes de façon à ce qu'ils soient disponibles pour ces paquets.

Il est important de noter que les fichiers du répertoire source du noyau n'appartiennent pas à root. Quand vous déballez un package en tant qu'utilisateur root (comme nous le faisons ici dans le chroot), les fichiers ont l'identifiant de l'utilisateur et du groupe du mainteneur du package sur son propre ordinateur. Ce n'est pas habituellement un problème pour tous les autres paquets que vous installez parce que vous supprimez le répertoire des sources après l'installation. Mais le répertoire des sources du noyau est souvent conservé un long moment, donc il existe une chance pour que l'identifiant utilisateur du mainteneur soit affecté à un utilisateur sur votre machine. Du coup, cette personne aurait le droit d'écriture sur les sources du noyau.

A la lumière de ceci, il est préférable de lancer chown -R 0:0 sur le répertoire linux-2.4.22 pour vous assurer que tous les fichiers appartiennent bien à l'utilisateur root.

Préparez l'installation des en-têtes :

make mrproper

Ceci nous assure que le répertoire des sources du noyau est totalement propre. L'équipe du noyau recommande que cette commande soit exécutée avant chaque compilation du noyau. Vous ne devez pas vous reposer sur un répertoire non nettoyé après son déballage.

Créez le fichier include/linux/version.h :

make include/linux/version.h

Créez le lien symbolique include/asm spécifique à la plateforme :

make symlinks

Installez les fichiers d'en-têtes spécifiques à la plateforme :

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

Installez les fichiers d'en-têtes inter-plate-forme :

cp -R include/linux /usr/include

Il existe quelques fichiers d'en-têtes du noyau utilisant le fichier d'en-tête autoconf.h. Comme nous n'avons pas encore configuré le noyau, nous avons besoin de créer ce fichier nous-même pour éviter des échecs de compilation. Créez un fichier autoconf.h vide :

touch /usr/include/linux/autoconf.h

Pourquoi nous copions les en-têtes du noyau et pourquoi nous ne créons pas de liens

Auparavant, une pratique commune consistait à créer des liens symboliques pour les répertoires /usr/include/{linux,asm} vers respectivement /usr/src/linux/include/{linux,asm}. Ceci est une mauvaise idée d'après cet extrait d'un message de Linus Torvalds sur la liste de diffusion du noyau Linux :

Je suggère que les personnes qui compilent des noyaux devraient :

 - ne pas créer un seul lien symbolique (sauf celui créé lors de la
construction du noyau, "linux/include/asm" qui est utilisé pour la compilation
du noyau lui-même).

Et oui, c'est ce que je fais. Mon répertoire /usr/src/linux a toujours les
anciens entêtes du noyau 2.2.13, même si je n'ai pas lancé cette version du
noyau depuis un _loong_ moment. Mais Glibc a été compilé avec, donc ces
entêtes correspondent aux objets de la bibliothèque.

Et cela correspond à l'environnement suggéré depuis au moins les cinq dernières 
années. Je ne sais pas pourquoi l'idée du lien symbolique est toujours vivante, 
comme un mauvais zombie. Pratiquement toutes les distributions conservent
l'idée du lien et tout le monde se souvient que les sources du noyau doivent
aller sous "/usr/src/linux" même si ce n'est plus vrai depuis _trèès_
longtemps.

La partie essentielle se trouve là où Linus indique que les fichiers d'entête doivent être ceux avec lesquels gblic a été compilé. Ces entêtes doivent être utilisés plus tard lorsque vous compilerez d'autres packages, car ce sont eux qui représentent les fichiers de bibliothèques. En copiant les entêtes, nous nous assurons qu'ils restent disponibles plus tard lors d'une mise à jour du noyau.

Notez qu'il est parfaitement normal d'avoir les sources du noyau dans /usr/src/linux, aussi longtemps que vous n'avez pas les liens symboliques /usr/include/{linux,asm}.

Contenu de Man-pages

Le package Man-pages contient plus de 1200 pages man. Cette documentation détaille les fonctions C et C++, décrit quelques fichiers périphériques importants et apporte les documents qui seraient autrement être manquants des autres packages.

Fichiers installés : différentes pages man

Dépendances d'installation de Man-pages

Man dépend de Bash, Coreutils, Make.

Installation de Man-pages

Installez Man-pages en lançant :

make install

Contenu de Glibc

(Dernière vérification effectuée auprès de la version 2.3.2.)

Glibc est une bibliothèque C qui apporte les appels système et les fonctions de base telles que open, malloc, printf, etc. La bibliothèque C est utilisée par tous les programmes liés dynamiquement.

Programmes installés : 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 et zic

Bibliothèques installées : 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 et libutil.[a,so]

Dépendances d'installation de Glibc

Glibc dépend de Bash, Binutils, Coreutils, Diffutils, Gawk, GCC, Gettext, Grep, Make, Perl, Sed, Texinfo.

Installation de Glibc

Le système de construction de Glibc est très solide et réalisera l'installation parfaitement même si notre fichier compilateur specs et l'éditeur de liens pointent toujours vers /tools. Nous ne pouvons pas ajuster le specs et l'éditeur de liens avant l'installation de Glibc parce que les tests autoconf de Glibc donneraient alors des résultats erronés et feraient ainsi échouer une construction propre.

Avant de commencer la construction de Glibc, rappelez-vous de déballer Glibc-linuxthreads de nouveau dans le répertoire glibc-2.3.2 et de supprimer les initialisations de toute variable d'environnement qui surchargerait une option d'optimisation par défaut.

Bien qu'il s'agisse d'un message sans gravité, la phase d'installation de Glibc se plaindra de l'absence de /etc/ld.so.conf. Corrigez cet ennuyeux petit message avec :

touch /etc/ld.so.conf

Ensuite, appliquez le même correctif que celui utilisé précédemment :

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

La documentation de Glibc recommande de construire Glibc en dehors du répertoire des sources, c'est-à-dire dans un répertoire dédié à la construction :

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

Maintenant, préparez la compilation de Glibc :

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

La signification des nouvelles options de configure est :

• --libexecdir=/usr/bin : Ceci fait que le programme pt_chown sera installé dans le répertoire /usr/bin.

• --with-headers=/usr/include : Ceci nous assure que les en-têtes du noyau compris dans /usr/include sont utilisées pour cette construction. Si vous ne passez pas cette option, alors les en-têtes de /tools/include sont utilisées, ce qui n'est évidemment pas idéal (bien qu'ils devraient être identiques). Utiliser cette option présente l'avantage de vous serez informer immédiatement si vous avez installé les en-têtes dans /usr/include.

Compilez le paquet :

make

Testez le résultat :

make check

Les notes de la suite de tests disponibles dans la section intitulée Installer Glibc-2.3.2 dans Chapitre 5 sont toujours appropriées ici. Assurez-vous de vous y référer en cas de doute.

Enfin, installez le paquet :

make install

Les locales qui peuvent permettre à votre système de parler une autre langue, n'ont pas été installées avec la commande ci-dessus. Faites-le ainsi :

make localedata/install-locales

Une alternative au lancement de la commande précédente est d'installer uniquement les locales dont vous avez besoin ou que vous voulez. Ceci est faisable avec la commande localedef. Une information là-dessus est disponible dans le fichier INSTALL du répertoire glibc-2.3.2. Néanmoins, il existe un certain nombre de locales essentielles pour passer les tests des futurs paquets correctement. Les instructions suivantes, remplaçant la commandes install-locales ci-dessus, installeront l'ensemble minimum de locales nécessaires pour exécuter les tests correctement :

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

Puis, construisez les pages man de linuxthreads :

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

Et installez-les :

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

Configurer Glibc

Nous avons besoin de créer le fichier /etc/nsswitch.conf, parce que, bien que Glibc puisse fournir un paramétrage par défaut lorsque ce fichier manque ou est corrompu, la Glibc ne fonctionne pas correctement pour le réseau. Notre zone horaire a également besoin d'être configurée.

Créez un nouveau fichier/etc/nsswitch.conf en exécutant ce qui suit:

cat > /etc/nsswitch.conf << "EOF"
# Debut de /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

# Fin de /etc/nsswitch.conf
EOF

Pour trouver votre zone horaire, lancez le script suivant :

tzselect

Quand vous aurez répondu à quelques questions concernant votre situation géographique, le script vous donnera le nom de votre zone horaire, quelque chose comme EST5EDT ou Canada/Eastern. Ensuite, créez le fichier /etc/localtime en lançant :

cp --remove-destination /usr/share/zoneinfo/Canada/Eastern /etc/localtime 

La signification de l'option est la suivante :

• --remove-destination : Ceci est nécessaire pour forcer la suppression du lien symbolique existant. La raison de la copie plutôt que la création d'un lien symbolique s'explique par la nécessité de fonctionner même si /usr se trouve sur une partition séparée. Ceci peut faire la différence, par exemple lorsque vous démarrez en mode simple utilisateur.

Bien sûr, remplacez Canada/Eastern par le nom de la zone horaire que le script tzselect vous a donné.

Configurer le chargeur dynamique

Par défaut, le chargeur dynamique (/lib/ld-linux.so.2) cherche dans /lib et /usr/lib les bibliothèques dynamiques qui sont nécessaires aux programmes que vous lancez. cependant, s'il y a des bibliothèques dans des répertoires autres que /lib et /usr/lib, vous devez les ajouter dans le fichier /etc/ld.so.conf afin que le chargeur dynamique les trouve. Les deux répertoires couramment utilisés pour recevoir de nouvelles bibliothèques sont /usr/local/lib et /opt/lib. Pour cette raison, nous devons ajouter ces répertoires dans la liste de recherche du chargeur dynamique.

Créez un nouveau fichier /etc/ld.so.conf en exécutant la commande suivante :

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

/usr/local/lib
/opt/lib

# Fin /etc/ld.so.conf
EOF

Contenu de Binutils

Binutils est une collection d'outils de développement de logiciels contenant un éditeur de liens, un assembleur et d'autres outils pour travailler avec des fichiers objet et des archives.

Programmes installés : addr2line, ar, as, c++filt, gprof, ld, nm, objcopy, objdump, ranlib, readelf, size, strings et strip

Bibliothèques installés : libiberty.a, libbfd.[a,so] et libopcodes.[a,so]

Dépendances d'installation de Binutils

Binutils dépend de Bash, Coreutils, Diffutils, GCC, Gettext, Glibc, Grep, Make, Perl, Sed, Texinfo.

Installation de Binutils

C'est le bon moment pour vérifier que vos pseudo-terminaux (PTY) fonctionnent correctement dans l'environnement chroot. Nous allons encore rapidement vérifier que tout est bien configuré en réalisant un simple test :

expect -c "spawn ls"

Si vous recevez le message :

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

Votre environnement chroot n'est pas correctement configuré pour les PTY. Dans ce cas, il n'y a aucune raison pour lancer les suites de tests pour Binutils et GCC jusqu'à la résolution de ce problème. Merci de vous référer à la section intitulée Monter le système de fichier proc et devfs et la section intitulée Créer les périphériques (Makedev-1.7), et de réaliser les étapes recommandées pour corriger le problème.

Ce paquet est connu pour mal se comporter si vous changez les options d'optimisation par défaut (en incluant les options -march et -mcpu). Donc, si vous avez défini des variables d'environnement qui surchargent les optimisations pas défaut, telles que CFLAGS et CXXFLAGS, nous vous recommandons de supprimer cette initialisation lors de la construction de Binutils.

La documentation de Binutils recommande de construire Binutils en dehors du répertoire des sources, c'est-à-dire dans un répertoire de construction dédié :

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

Maintenant, préparez la compilation de Binutils :

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

Compilez le paquet :

make tooldir=/usr

Normalement, tooldir (le répertoire où se trouveront les exécutables) est initialisé à $(exec_prefix)/$(target_alias), ce qui sera compris comme, par exemple, /usr/i686-pc-linux-gnu. Comme nous ne construisons que notre propre système, nous n'avons pas besoin d'un répertoire spécifique à une cible dans /usr. Cette configuration serait utilisée si le système était utilisé pour faire de la cross-compilation (par exemple pour compiler un paquet sur une machine Intel en générant du code exécutable sur des machines à base de PowerPC).

Testez le resultat :

make check

Les notes de la suite de tests données lors du la section intitulée Installer Binutils-2.14 - Pass 2 dans Chapitre 5 sont toujours appropriées ici. Assurez-vous de vous y référer si vous avez un quelconque doute.

Installez le paquet :

make tooldir=/usr install

Installez le fichier d'en-tête libiberty nécessaire à certains paquets :

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

Contenu de GCC

Le package GCC contient le compilateur GNU, incluant les compilateurs C et C++.

Programmes installés : c++, cc (lien vers gcc), cc1, cc1plus, collect2, cpp, g++, gcc, gccbug et gcov

Bibliothèques installées : libgcc.a, libgcc_eh.a, libgcc_s.so, libstdc++.[a,so] et libsupc++.a

Dépendances d'installation de GCC

GCC dépend de Bash, Binutils, Coreutils, Diffutils, Findutils, Gawk, Gettext, Glibc, Grep, Make, Perl, Sed, Texinfo.

Installation de GCC

Ce package est connu pour mal se comporter si vous changez les options d'optimisation par défaut (en incluant les options -march et -mcpu). Donc, si vous avez défini des variables d'environnement qui surchargent les optimisations pas défaut, telles que CFLAGS et CXXFLAGS, nous vous recommandons de supprimer cette initialisation lors de la construction de GCC.

Cette fois, nous allons construire le compilateur C et le compilateur C++, donc vous devez déballer les archives tar GCC-core et GCC-g++, qui utiliseront le même répertoire. Vous devrez aussi certainement extraire le paquet GCC-testsuite. Le paquet GCC complet contient encore plus de compilateurs. Les instructions de construction pour ceux-ci se trouvent sur 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

Le second correctif supprime ici l'installation de libiberty à partir de GCC, car nous utilisons celle fournie par binutils. Faites attention à ne pas appliquer le correctif "GCC specs" du chapitre 5.

La documentation GCC recommande de construire GCC en dehors du répertoire source, c'est-à-dire dans un répertoire de construction dédié :

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

Maintenant, préparez la compilation de GCC :

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

Compilez le package :

make

Testez le résultat mais ne vous arrêtez pas aux erreurs (vous vous en rappelerez) :

make -k check

Les notes de la suite de tests de la section intitulée Installer GCC-3.3.1 - Pass 2 dans Chapitre 5 sont encore une fois appropriées ici. Référerez-vous à celles-ci si vous avez des doutes.

Et, installez le paquet :

make install

Quelques paquets s'attendent à ce que le préprocesseur C soit installé dans le répertoire /lib. Pour utiliser ces paquets, créez ce lien symbolique :

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

Beaucoup de paquets utilisent le nom cc pour appeler le compilateur C. Pour satisfaire ces paquets, créez le lien symbolique :

ln -s gcc /usr/bin/cc

Contenu de Coreutils

Le package Coreutils contient un grand ensemble d'utilitaires shell basiques.

Programmes installés : 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 et yes

Dépendances d'installation de Coreutils

Coreutils dépend de Bash, Binutils, Coreutils, Diffutils, GCC, Gettext, Glibc, Grep, Make, Perl, Sed.

Installation de Coreutils

Normalement, la fonctionnalité de uname est quelque peu cassée, dans le fait que le paramètre -p renvoie toujours "unknown". Le correctif suivant corrige ce comportement pour les architectures Intel :

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

Nous ne voulons pas que Coreutils installe sa version du programme hostname parce qu'il est inférieur à la version fournie par Net-tools. Empêchez cette installation en appliquant un correctif :

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

Maintenant, préparez la compilation de Coreutils :

./configure --prefix=/usr

Compilez le paquet :

make

Le programme su de Coreutils n'était pas installé parce qu'il avait besoin des privilèges de root pour le faire. Nous en avons besoin quelques instants pour la suite de tests. Donc, nous contournons le problème en l'installant maintenant :

make install-root

Ce paquet dispose d'une suite de tests réalisant un ensemble de vérifications pour s'assurer que tout est construit correctement. Néanmoins, cette suite de tests particuliers fait quelques suppositions sur la présence d'utilisateurs et de groupes non root qui ne s'appliquent pas aussi tôt dans la construction de LFS. Nous créons donc un utilisateur système dummy et deux groupes dummy pour permettre aux tests de s'exécuter correctement. Si vous décidez de ne pas lancer cette suite de tests, passez directement à la section "Installez le paquet". Les commandes suivantes prépareront la suite de tests. Créez l'utilisateur et les deux groupes :

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

Certains tests doivent être lancés en tant que root :

make check-root

Le reste des tests est lancé en tant qu'utilisateur dummy :

su dummy -c "make RUN_EXPENSIVE_TESTS=yes check"

Supprimez les noms d'utilisateur et de groupe dummy :

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

Installez le paquet :

make install

Et déplacez quelques programmes vers leur bon emplacement :

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

Finalement, créez quelques liens symboliques nécessaires :

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

Contenu de Zlib

Le package Zlib contient la bibliothèque zlib, utilisé par certains programmes pour ses fonctions de compression et de décompression.

Bibliothèques installées : libz[a,so]

Dépendances d'installation de Zlib

Zlib dépend de Binutils, Coreutils, GCC, Glibc, Make, Sed.

Installation de Zlib

Zlib a un problème de dépassement de tampon potentiel dans sa fonction gzprintf(), qui, bien que difficile à être exploitée, devrait être corrigée avec l'application de ce correctif :

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

Maintenant, préparez la compilation de Zlib :

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

Note: Zlib est connu pour construire sa bibliothèque partagée de façon incorrecte si un CFLAGS est spécifié dans son environnement. Si vous utilisez vos propres variables CFLAGS, assurez-vous d'ajouter la directive -fPIC à cette étape et de la supprimer après.

Compilez le paquet :

make

Installez les bibliothèques partagées :

make install

Maintenant, construisez aussi les bibliothèques non partagées :

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

Ce pacquet dispose d'une suite de tests, réalisant plusieurs tests pour s'assurer que le programme a été construit correctement. Si vous décidez de le lancer, la commande suivante fera le nécessaire :

make test

Enfin, installez le paquet :

make install

La bibliothèque partagée Zlib devrait être installée dans le répertoire /lib. De cette façon, au cas où vous devriez redémarrer sans le répertoire /usr, les programmes systèmes vitaux auront toujours accès à la bibliothèque :

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

Le lien symbolique /usr/lib/libz.so pointe vers un fichier qui n'existe plus parce que nous l'avons déplacé. Créez un lien symbolique vers le nouvel emplacement de la bibliothèque :

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

Zlib n'installe pas sa page man. Lancez cette commande pour installer cette documentation :

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

Contenu de Lfs-Utils

Le package Lfs-Utils contient quelques programmes divers provenant de plusieurs packages mais qui ne sont pas assez importants pour disposer de leur propre package.

Programmes installés : mktemp, tempfile, http-get et iana-net

Fichiers installés : protocols, services

Dépendances d'installation de Lfs-Utils

(Les dépendances n'ont pas encore été vérifié.)

Installation de Lfs-Utils

Compilez le paquet :

make

Et installez-le :

make install

Maintenant, copiez les deux fichiers inclus dans l'archive tar Lfs-Utils vers leur destination :

cp etc/{services,protocols} /etc

Le fichier /etc/services est utilisé pour convertir les numéros de services en noms lisibles par des humains alors que le fichier /etc/protocols fait la même chose pour les numéros de protocole.

Contenu de Findutils

Le package Findutils contient les programmes de recherche de fichiers, soit en direct (en faisant une recherche récursive en direct à travers les répertoires et seulement en affichant des fichiers qui remplissent ses spécifications) soit en cherchant à travers une base de données.

Programmes installés : bigram, code, find, frcode, locate, updatedb et xargs

Dépendances d'installation de Findutils

Findutils dépend de Bash, Binutils, Coreutils, Diffutils, GCC, Gettext, Glibc, Grep, Make, Sed.

Installer Findutils

Préparez la compilation de Findutils :

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

Par défaut, la base de données updatedb se trouve dans /usr/var. Pour rendre l'emplacement du fichier /var/lib/misc/locatedb compatible avec FHS, utilisez l'option --localstatedir=/var/lib/misc de configure.

Compilez le paquet :

make

Ce paquet dispose d'une suite de tests, réalisant plusieurs tests pour s'assurer que le programme a été construit correctement. Si vous décidez de le lancer, la commande suivante fera le nécessaire :

make check

Et installez le paquet :

make install

Contenu de Gawk

Gawk est une implémentation de awk qui est utilisée pour manipuler des fichiers texte.

Programmes installés : awk (lien vers gawk), gawk, gawk-3.1.3, grcat, igawk, pgawk, pgawk-3.1.3 et pwcat.

Dépendances d'installation de Gawk

Gawk dépend de Bash, Binutils, Coreutils, Diffutils, GCC, Gettext, Glibc, Grep, Make, Sed.

Installation de Gawk

Tout d'abord, appliquez un correctif pour résoudre les problèmes suivants :

• L'emplacement par défaut de Gawk pour certains de ses exécutables est $prefix/libexec/awk. Cet emplacement n'est pas compatible avec FHS, qui ne mentionne à aucun moment un répertoire nommé libexec. Le correctif rend possible le passage d'une option --libexecdir au script configure, de façon à ce que nous utilisions un emplacement plus approprié pour les binaires grcat et pwcat : /usr/bin.

• Le répertoire des données par défaut de Gawk est $prefix/share/awk. Mais les répertoires spécifiques aux paquets devraient être nommés suivant le nom du paquet et son numéro de version (par exemple, gawk-7.7.2.) et non pas simplement par son nom de paquet car il pourrait exister plusieurs versions d'un paquet installé sur le système. Le correctif modifie le nom du répertoire de données en un $prefix/share/gawk-3.1.3 plus correct.

• Le correctif nous assure aussi que le répertoire des données et son contenu sont supprimés avec un make uninstall.

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

Maintenant, préparez la compilation de Gawk :

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

Compilez le paquet :

make

Ce paquet dispose d'une suite de tests qui s'assure que le programme a été construit correctement. Si vous décidez de le lancer, la commande suivante fera le nécessaire :

make check

Enfin, installez le paquet :

make install

Contenu de Ncurses

(Dernière version effectuée auprès de la version 5.3.)

Le package Ncurses apporte des bibliothèques de gestion de caractères et de terminaux, incluant les panneaux et les menus.

Programmes installés : captoinfo (lien vers tic), clear, infocmp, infotocap (lien vers tic), reset (lien vers tset), tack, tic, toe, tput et tset

Bibliothèques installées : libcurses.[a,so] (lien vers libncurses.[a,so]), libform.[a,so], libmenu.[a,so], libncurses++.a, libncurses.[a,so], libpanel.[a,so]

Dépendances d'installation de Ncurses

Ncurses dépend de Bash, Binutils, Coreutils, Diffutils, Gawk, GCC, Glibc, Grep, Make, Sed.

Installation de Ncurses

Tout d'abord, corrigez deux petits bogues :

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

Le premier correctif s'occupe du fichier d'en-tête etip.h alors que le second empêche les messages d'avertissement dû à l'utilisation d'en-têtes obsolètes.

Maintenant, préparez la compilation de Ncurses :

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

Compilez le paquet :

make

Installez le paquet :

make install

Donnez le droit d'exécution pour les bibliothèques Ncurses :

chmod 755 /usr/lib/*.5.3

Et corrigez une bibliothèque qui ne devrait pas être exécutable :

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

Déplacez les bibliothèques dans le répertoire /lib, où elles devraient se trouver :

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

Comme les bibliothèques ont été déplacées dans /lib, quelques liens symboliques pointent actuellement vers des fichiers inexistants. Recréez ces liens :

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

Alternatives à Vim

Si vous préférez utiliser un autre éditeur, comme Emacs, Joe ou Nano, au lieu de Vim, jetez un oeil sur http://www.linuxfromscratch.org/blfs/view/stable/postlfs/editors.html pour des instructions d'installation.

Contenu de Vim

Le package Vim contient un éditeur de texte configurable construit pour permettre une édition efficace du texte.

Programmes installés : efm_filter.pl, efm_perl.pl, ex (lien vers vim), less.sh, mve.awk, pltags.pl, ref, rview (lien vers vim), rvim (lien vers vim), shtags.pl, tcltags, vi (lien vers vim), view (lien vers vim), vim, vim132, vim2html.pl, vimdiff (lien vers vim), vimm, vimspell.sh, vimtutor et xxd

Dépendances d'installation de Vim

Vim dépend de Bash, Binutils, Coreutils, Diffutils, GCC, Glibc, Grep, Make, Ncurses, Sed.

Installation de Vim

Modifiez les emplacements par défaut des fichiers vimrc et gvimrc pour /etc.

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

Maintenant, préparez la compilation de Vim :

./configure --prefix=/usr

Compilez le paquet :

make

Et installez le paquet :

make install

Vim peut s'exécuter dans l'ancien mode vi en créant un lien symbolique, avec la commande suivante :

ln -s vim /usr/bin/vi

Si vous pensez installer le système X Window sur votre système LFS, vous pourriez vouloir recompiler Vim après avoir installé X. Vim dispose d'une version GUI très agréable de l'éditeur, mais nécessitant l'installation de X et de quelques autres bibliothèques. Pour plus d'informations, lisez la documentation de Vim.

Configurer Vim

Par défault, vim fonctionne en mode compatible vi. Certaines personnes l'aiment comme cela, mais nous avons une forte préférence pour faire tourner Vim en mode Vim (autrement nous n'aurions pas inclus vim dans ce livre mais l'original vi). Créez /root/.vimrc en exécutant ceci :

cat > /root/.vimrc << "EOF"
" Debut de /root/.vimrc

set nocompatible
set bs=2

" Fin de /root/.vimrc
EOF

Contenu de M4

M4 est un processeur de macro. Il copie l'entrée vers la sortie, exécutant les macros qu'il trouve. Les macros sont soit intégrées soit définies par l'utilisateur, et peuvent prendre n'importe quel nombre d'arguments. En plus d'exécuter certaines macros, m4 dispose de fonctions intégrées permettant d'inclure des fichiers nommés, de lancer des commandes Unix, de réaliser quelques calculs arithmétiques, de manipuler du texte de différentes façons, d'utiliser la récursivité, etc... Le programme m4 est utilisé soit comme interface pour un compilateur soit directement comme un processeur de macros.

Programme installé : m4

Dépendances d'installation de M4

M4 dépend de Bash, Binutils, Coreutils, Diffutils, GCC, Gettext, Glibc, Grep, Make, Perl, Sed.

Installation de M4

Préparez la compilation de M4 :

./configure --prefix=/usr

Compilez le paquet :

make

Ce paquet dispose d'une suite de tests, réalisant plusieurs tests pour s'assurer que le programme a été construit correctement. Si vous décidez de le lancer, la commande suivante fera le nécessaire :

make check

Enfin, installez le paquet :

make install

Contenu de Bison

Bison est un générateur de l'analyseur, un remplacement pour yacc. Bison génère un programme analysant la structure d'un fichier texte.

Programmes installés : bison et yacc

Bibliothèques installés : liby.a

Dépendances d'installation de Bison

Bison dépend de Bash, Binutils, Coreutils, Diffutils, GCC, Gettext, Glibc, Grep, M4, Make, Sed.

Installation de Bison

Tout d'abord, nous utilisons un correctif pour bison, récupéré du CVS, car il corrige un problème de compilation mineur avec certains paquets :

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

Préparez la compilation de Bison :

./configure --prefix=/usr

Compilez le paquet :

make

Ce paquet dispose d'une suite de tests, réalisant plusieurs tests pour s'assurer que le programme a été construit correctement. Si vous décidez de le lancer, la commande suivante fera le nécessaire :

make check

Et installez le paquet :

make install

Contenu de Less

Le programme less est un paginateur de fichier (ou un afficheur de texte). Il affiche le contenu d'un fichier et permet le défilement du texte. Less dispose de quelques fonctionnalités qui ne sont pas incluses dans le paginateur << more >>, telle que le défilement arrière.

Programmes installés : less, lessecho et lesskey

Dépendances d'installation de Less

Less dépend de Bash, Binutils, Coreutils, Diffutils, GCC, Glibc, Grep, Make, Ncurses, Sed.

Installation de Less

Préparez la compilation de Less :

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

La signification de l'option configure est :

• --sysconfdir=/etc : Cette option indique aux programmes créés par le package de rechercher leur fichiers de configuration dans /etc.

Compilez le paquet :

make

Et installez-le :

make install

Contenu de Groff

Le package Groff inclut plusieurs programmes pour traiter du texte et le formatter. Groff traduit du texte et des commandes spécifiques en une sortie formattée, telle que ce que vous voyez dans une page man.

Programmes installés : addftinfo, afmtodit, eqn, eqn2graph, geqn (lien vers eqn), grn, grodvi, groff, groffer, grog, grolbp, grolj4, grops, grotty, gtbl (lien vers tbl), hpftodit, indxbib, lkbib, lookbib, mmroff, neqn, nroff, pfbtops, pic, pic2graph, post-grohtml, pre-grohtml, refer, soelim, tbl, tfmtodit, troff et zsoelim (lien vers soelim)

Dépendances d'installation de Groff

Groff dépend de Bash, Binutils, Coreutils, Diffutils, Gawk, GCC, Glibc, Grep, Make, Sed.

Installation de Groff

Groff s'attend à ce que la variable d'environnement PAGE contienne la taille par défaut du papier. Pour ceux habitant aux Etats-Unis, la commande ci-dessous est appropriée. Si vous vivez ailleurs, vous pouvez changer PAGE=letter par PAGE=A4.

Préparez la compilation de Groff :

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

Compilez le paquet :

make

Puis, installez-le :

make install

Quelques programmes de documentation, tels que xman, ne fonctionneront pas correctement sans les liens symboliques suivants :

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

Contenu de Sed

sed est un éditeur en flux. Un éditeur en flux est utilisé pour réaliser des transformations de texte basique sur une entrée en flux (un fichier ou une entrée à partir d'un tuyau).

Programme installé : sed

Dépendances d'installation de Sed

(Dernière vérification effectuée auprès de la version 3.02.)

Sed dépend de Bash, Binutils, Coreutils, Diffutils, GCC, Gettext, Glibc, Grep, Make, Texinfo.

Installation de Sed

Préparez la compilation de Sed :

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

Compilez le paquet :

make

Ce paquet dispose d'une suite de tests, réalisant plusieurs tests pour s'assurer que le programme a été construit correctement. Si vous décidez de le lancer, la commande suivante fera le nécessaire :

make check

Enfin, installez le paquet :

make install

Contenu de Flex

Le package Flex est utilisé pour générer des programmes de reconnaissance de modèles dans du texte.

Programmes installés : flex, flex++ (lien vers flex) et lex

Bibliothèque installée : libfl.a

Dépendances d'installation de Flex

Flex dépend de Bash, Binutils, Bison, Coreutils, Diffutils, GCC, Gettext, Glibc, Grep, M4, Make, Sed.

Installation de Flex

Préparez la compilation de Flex :

./configure --prefix=/usr

Compilez le paquet :

make

Ce paquet dispose d'une suite de tests, réalisant plusieurs tests pour s'assurer que le programme a été construit correctement. Si vous décidez de le lancer, la commande suivante fera le nécessaire :

make bigcheck

Et installez le paquet :

make install

Certains paquets s'attendent à trouver la bibliothèque Lex dans /usr/lib. Créez un lien symbolique pour prendre ceci en compte :

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

Quelques programmes ne connaissent pas encore flex et essaient de lancer son prédécesseur lex. Pour supporter ces programmes, créer un script shell nommé lex appelant flex dans son mode d'émulation Lex :

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

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

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

Contenu de Gettext

Le package Gettext est utilisé pour l'internationalisation et la localisation. Les programmes peuvent êtres compilés avec le support de la langue native ('Native Language Support' ou NLS) qui leur permettent d'afficher les messages dans la langue native de l'utilisateur.

Programmes installés : 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 et xgettext

Bibliothèques installées : libasprintf[a,so], libgettextlib[a,so], libgettextpo[a,so] et libgettextsrc[a,so]

Dépendances d'installation de Gettext

Gettext dépend de Bash, Binutils, Bison, Coreutils, Diffutils, Gawk, GCC, Glibc, Grep, Make, Sed.

Installation de Gettext

Préparez la compilation de Gettext :

./configure --prefix=/usr

Compilez le paquet :

make

Ce paquet dispose d'une suite de tests, réalisant plusieurs tests pour s'assurer que le programme a été construit correctement. Si vous décidez de le lancer, la commande suivante fera le nécessaire :

make check

Enfin, installez le package :

make install

Contenu de Net-tools

Le package Net-tools contient une collection de programmes formant la base réseau sous Linux.

Programmes installés : arp, dnsdomainname (lien vers hostname), domainname (lien vers hostname), hostname, ifconfig, nameif, netstat, nisdomainname (lien vers hostname), plipconfig, rarp, route, slattach et ypdomainname (lien vers hostname)

Dépendances d'installation de Net-tools

Net-tools dépend de Bash, Binutils, Coreutils, GCC, Glibc, Make.

Installation de Net-tools

Si vous ne savez quoi répondre à toutes les questions posées pendant la phase du make config ci-dessous, acceptez les valeurs par défaut. Elles sont tout à fait bien dans la majorité des cas. Un ensemble de questions vous est posé sur les protocoles réseau que vous avez activé sur votre noyau. Les réponses par défaut feront que tous les outils de ce package fonctionneront avec les protocoles les plus fréquents : TCP, PPP et quelques autres encore. Vous aurez toujours besoin d'activer réellement ces protocoles dans le noyau -- vous devez donc dire simplement au package d'inclure ces protocoles dans ces programmes, mais c'est au noyau de rendre les protocoles disponibles.

Tout d'abord, corrigez un léger problème de syntaxe dans les sources avec le programme mii-tool :

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

Maintenant, préparez la compilation de Net-tools avec :

make config

Si vous souhaitez accepter les paramètrages par défaut, vous pouvez passer les questions générées par make config en lançant yes "" | make config à la place.

Compilez le paquet :

make

Et installez-le :

make update

Contenu de Inetutils

Le package Inetutils contient des clients et des serveurs réseau.

Programmes installés : ftp, ping, rcp, rlogin, rsh, talk, telnet et tftp

Dépendance d'installation d'Inetutils

Inetutils dépend de Bash, Binutils, Coreutils, Diffutils, GCC, Glibc, Grep, Make, Ncurses, Sed.

Installation de Inetutils

Préparez la compilation d'Inetutils :

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

La signification des options de configure est :

• --disable-syslogd : Cette option empêche inetutils d'installer le démon de journalisation du système, installé avec le package Sysklogd.

• --disable-logger : Cette option empêche inetutils d'installer le programme logger, utilisé par des scripts pour passer des messages au démon de journalisation du système. Nous ne l'installons pas car Util-linux installe une version bien supérieure.

• --disable-whois : Cette option désactive la construction du client whois d'inetutils, qui est affreusement obsolète. Des instructions pour un meilleur client whois se trouvent dans le livre BLFS.

• --disable-servers : Ceci désactive l'installation de différents serveurs réseau inclus dans le package Inetutils. Ces serveurs ne sont absolument pas appropriés dans un système LFS de base. Certains sont non sécurisés par nature et sont seulement considérés sûr sur des réseaux de confiance. Plus d'information est disponible sur http://www.linuxfromscratch.org/blfs/view/stable/basicnet/inetutils.html. Notez que des programmes de substitution bien supérieurs sont disponibles pour un bon nombre de ces serveurs.

Compilez le paquet :

make

Installez-le :

make install

Et déplacez le programme ping au bon emplacement :

mv /usr/bin/ping /bin

Contenu de Perl

Le package Perl contient perl, l'acronyme de Practical Extraction and Report Language (Langage pratique d'extraction et de rapport). Perl combine certaines des meilleurs fonctionnalités des langages C, sed, awk et sh en un seul langage extrêmement puissant.

Programmes installés : a2p, c2ph, dprofpp, enc2xs, find2perl, h2ph, h2xs, libnetcfg, perl, perl5.8.0 (lien vers perl), perlbug, perlcc, perldoc, perlivp, piconv, pl2pm, pod2html, pod2latex, pod2man, pod2text, pod2usage, podchecker, podselect, psed (lien vers s2p), pstruct (lien vers c2ph), s2p, splain and xsubpp

Bibliothèques installées : (trop nombreux pour les nommer toutes)

Dépendances d'installation de Perl

Perl dépend de Bash, Binutils, Coreutils, Diffutils, Gawk, GCC, Glibc, Grep, Make, Sed.

Installation de Perl

Préparez la compilation de Perl :

./configure.gnu --prefix=/usr

Si vous voulez plus de contrôle sur la façon dont Perl se configure pour se contruire, vous pouvez lancer le script interactif Configure à la place et modifier ainsi la façon dont Perl est construit. Si vous pensez que vous pouvez vivre avec les valeurs par défaut (corrects) que Perl détecte automatiquement, alors utilisez simplement la commande ci-dessous.

Compilez le paquet :

make

Ce paquet dispose d'une suite de tests réalisant un certain nombre de tests pour s'assurer que tout est construit correctement. Si vous décidez de le lancer, vous devez tout d'abord créé un simple fichier /etc/hosts, nécessaire pour que quelques tests puissent comprendre le nom localhost:

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

Maintenant, lancez les tests, si vous le souhaitez :

make test

Enfin, installez le paquet :

make install

Contenu de Texinfo

Le package Texinfo contient des programmes utilisés pour lire, écrire et convertir des documents Info, qui apporte une documentation système.

Programmes installés : info, infokey, install-info, makeinfo, texi2dvi et texindex

Dépendances d'installation de Texinfo

Texinfo dépend de Bash, Binutils, Coreutils, Diffutils, GCC, Gettext, Glibc, Grep, Make, Ncurses, Sed.

Installation de Texinfo

Préparez la compilation de Texinfo :

./configure --prefix=/usr

Compilez le package :

make

Ce paquet dispose d'une suite de tests, réalisant plusieurs tests pour s'assurer que le programme a été construit correctement. Si vous décidez de le lancer, la commande suivante fera le nécessaire :

make check

Installez le paquet :

make install

Et installez de façon optionnelle les composants appartenant à une installation TeX :

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

La signification du paramètre de make est :

• TEXMF=/usr/share/texmf : La variable TEXMF de make contient l'emplacement de la racine de TeX si, par exemple, vous installez le package TeX plus tard.

Contenu d'Autoconf

Autoconf crée des scripts shell qui configurent automatiquement du code source.

Programmes installés : autoconf, autoheader, autom4te, autoreconf, autoscan, autoupdate et ifnames

Dépendances d'installation d'Autoconf

Autoconf dépend de Bash, Coreutils, Diffutils, Grep, M4, Make, Perl, Sed.

Installation d'Autoconf

Préparez la compilation d'Autoconf :

./configure --prefix=/usr

Compilez le paquet :

make

Ce paquet dispose d'une suite de tests, réalisant plusieurs tests pour s'assurer que le programme a été construit correctement. Si vous décidez de le lancer, la commande suivante fera le nécessaire :

make check

Et installez le paquet :

make install

Contenu d'Automake

Automake génère des fichiers Makefile.in, à utiliser avec Autoconf.

Programmes installés : acinstall, aclocal, aclocal-1.6, automake, automake-1.6, compile, config.guess, config.sub, depcomp, elisp-comp, install-sh, mdate-sh, missing, mkinstalldirs, py-compile, ylwrap

Dépendances d'installation d'Automake

Automake dépend de Autoconf, Bash, Coreutils, Diffutils, Grep, M4, Make, Perl, Sed.

Installation de Automake

Préparez la compilation d'Automake :

./configure --prefix=/usr

Compilez le paquet :

make

Ce paquet dispose d'une suite de tests, réalisant plusieurs tests pour s'assurer que le programme a été construit correctement. Si vous décidez de le lancer, la commande suivante fera le nécessaire :

make check

Installez le paquet :

make install

Et, créez le lien symbolique nécessaire :

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

Contenu de Bash

Bash, acronyme de Bourne-Again SHell, est un interpréteur de commande très répandu sur les systèmes Unix. Il se charge d'interpréter et d'évaluer les commandes que l'utilisateur entre sur l'entrée standard (le clavier), comme par exemple lancer un programme.

Programmes installés : bash, sh (lien vers bash) et bashbug

Dépendances d'installation de Bash

Bash dépend de Binutils, Coreutils, Diffutils, Gawk, GCC, Glibc, Grep, Make, Ncurses, Sed.

Installation de Bash

Bash contient un certain nombres de bogues faisant qu'il ne se comporte pas de la façon attendue. Corrigez ce comportement avec le correctif suivant :

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

Préparez la compilation de Bash :

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

Compilez le paquet :

make

Ce paquet dispose d'une suite de tests, réalisant plusieurs tests pour s'assurer que le programme a été construit correctement. Si vous décidez de le lancer, la commande suivante fera le nécessaire :

make tests

Installez le paquet :

make install

Et rechargez le nouveau programme bash :

exec /bin/bash --login +h

Contenu de File

File est un utilitaire servant à déterminer les types de fichiers.

Programme installé : file

Bibliothèque installée : libmagic.[a,so]

Dépendances d'installation de File

File dépend de Bash, Binutils, Coreutils, Diffutils, GCC, Glibc, Grep, Make, Sed, Zlib.

Installation de File

Préparez la compilation de File :

./configure --prefix=/usr

Compilez le paquet :

make

Et, installez-le :

make install

Contenu de Libtool

GNU libtool est un outil générique de support de scripts. Libtool cache la complexité en utilisant les bibliothèques partagées derrière une interface portable cohérente.

Programmes installés : libtool et libtoolize

Bibliothèques installées : libltdl.[a,so]

Dépendances d'installation de Libtool

Libtool dépend de Bash, Binutils, Coreutils, Diffutils, GCC, Glibc, Grep, Make, Sed.

Installation de Libtool

Préparez la compilation de Libtool :

./configure --prefix=/usr

Compilez le package :

make

Ce paquet dispose d'une suite de tests, réalisant plusieurs tests pour s'assurer que le programme a été construit correctement. Si vous décidez de le lancer, la commande suivante fera le nécessaire :

make check

Enfin, installez le paquet :

make install

Contenu de Bzip2

Bzip2 est un compresseur de fichiers qui arrive habituellement à une meilleure compression que ne le fait gzip traditionel.

Programmes installés : bunzip2 (lien vers bzip2), bzcat (lien vers bzip2), bzcmp, bzdiff, bzegrep, bzfgrep, bzgrep, bzip2, bzip2recover, bzless et bzmore

Bibliothèques installées : libbz2.a, libbz2.so (lien vers libbz2.so.1.0), libbz2.so.1.0 (lien vers libbz2.so.1.0.2) et libbz2.so.1.0.2

Dépendances d'installation de Bzip2

Bzip2 dépend de Bash, Binutils, Coreutils, Diffutils, GCC, Glibc, Make.

Installation de Bzip2

Préparez la compilation de Bzip2 avec :

make -f Makefile-libbz2_so
make clean

L'option -f fait que Bzip2 est construit avec un fichier Makefile différent, dans ce cas le fichier Makefile-libbz2_so, qui crée une bibliothèque partagée libbz2.so et la lie aux utilitaires.

Compilez le paquet :

make

Installez-le :

make install

Et installez le binaire bzip2 dans le répertoire /bin en ajoutant les liens symboliques nécessaires. Puis, faites un peu de ménage :

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

Contenu de Diffutils

Les programmes de ce package vous montre les différences entre les deux fichiers ou répertoires. Son utilisation la plus commune est la création de correctifs.

Programmes installés : cmp, diff, diff3 et sdiff

Dépendances d'installation de Diffutils

Diffutils dépend de Bash, Binutils, Coreutils, Diffutils, GCC, Gettext, Glibc, Grep, Make, Sed.

Installation de Diffutils

Préparez la compilation de Diffutils :

./configure --prefix=/usr

Compilez le paquet :

make

Et installez-le :

make install

Contenu d'Ed

GNU ed est un éditeur par lignes compatible POSIX.

Programmes installés : ed et red (lien vers ed)

Dépendances d'installation de Ed

Ed dépend de Bash, Binutils, Coreutils, Diffutils, GCC, Glibc, Grep, Make, Sed.

Installation de Ed

Ed utilise normalement la fonction mktemp pour créer des fichiers temporaires dans /tmp, mais cette fonctionnalité contient une vulnérabilité (voir la section sur les fichiers temporaires dans http://en.tldp.org/HOWTO/Secure-Programs-HOWTO/avoid-race.html). Le correctif suivant fait que Ed utilise mkstemp à la place, ce qui est la façon recommandée de créer des fichiers temporaires.

Appliquez le correctif :

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

Maintenant, préparez la compilation de Ed :

./configure --prefix=/usr

Compilez le paquet :

make

Ce paquet dispose d'une suite de tests, réalisant plusieurs tests pour s'assurer que le programme a été construit correctement. Si vous décidez de le lancer, la commande suivante fera le nécessaire :

make check

Installez le paquet :

make install

Et, déplacez les programmes vers le répertoire /bin de façon à ce qu'ils puissent être utilisés au cas où la partition /usr ne serait pas disponible.

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

Contenu de Kbd

Kbd contient des fichiers de codage des touches et des utilitaires pour le clavier.

Programmes installés : chvt, deallocvt, dumpkeys, fgconsole, getkeycodes, getunimap, kbd_mode, kbdrate, loadkeys, loadunimap, mapscrn, openvt, psfaddtable (lien vers psfxtable), psfgettable (lien vers psfxtable), psfstriptable (lien vers psfxtable), psfxtable, resizecons, setfont, setkeycodes, setleds, setlogcons, setmetamode, setvesablank, showconsolefont, showkey, unicode_start et unicode_stop

Dépendances d'installation de Kbd

Kbd dépend de Bash, Binutils, Bison, Coreutils, Diffutils, Flex, GCC, Gettext, Glibc, Grep, Gzip, M4, Make, Sed.

Installation de Kbd

Par défaut, certains des utilitaires de Kbd (setlogcons, setvesablank et getunimap) ne sont pas installés. Tout d'abord, activez la compilation de ces utilitaires :

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

Maintenant, préparez la compilation de Kbd :

./configure

Compilez le paquet :

make

Et installez-le :

make install

Contenu de E2fsprogs

E2fsprogs apporte des utilitaires du système de fichiers ext2. Il supporte aussi le système de fichiers ext3 avec le support de la journalisation.

Programmes installés : 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 et uuidgen.

Bibliothèques installées : libblkid.[a,so], libcom_err.[a,so], libe2p.[a,so], libext2fs.[a,so], libss.[a,so] et libuuid.[a,so]

Dépendances d'installation d'E2fsprogs

E2fsprogs dépend de Bash, Binutils, Coreutils, Diffutils, Gawk, GCC, Gettext, Glibc, Grep, Make, Sed, Texinfo.

Installation de E2fsprogs

Il est recommandé de construire E2fsprogs en dehors du répertoire des sources :

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

Préparez la compilation d'E2fsprogs :

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

La signification des options de configure est :

• --with-root-prefix="" : Certains programmes (tel que le programme e2fsck) sont considérés comme essentiels. Quand, par exemple, /usr n'est pas monté, ces programmes essentiels doivent tout de même être accessibles. Ils appartiennent à des répertoires comme /lib et /sbin. Si cette option n'est pas passé au script configure d'E2fsprogs, les programmes seront placés dans le répertoire, ce qui n'est pas ce que nous souhaitons.

• --enable-elf-shlibs : Ceci crée les bibliothèques partagées que certains des programmes de ce paquet utilisent.

Compilez le paquet :

make

Ce paquet dispose d'une suite de tests, réalisant plusieurs tests pour s'assurer que le programme a été construit correctement. Si vous décidez de le lancer, la commande suivante fera le nécessaire :

make check

Installez la plupart du paquet :

make install

Et installez aussi les bibliothèques partagées :

make install-libs

Contenu de Grep

Grep est un programme utilisé pour imprimer des lignes d'un fichier ressemblant à un modèle spécifié.

Programmes installés : egrep (lien vers grep), fgrep (lien vers grep) et grep

Dépendances d'installation de Grep

Grep dépend de Bash, Binutils, Coreutils, Diffutils, GCC, Gettext, Glibc, Make, Sed, Texinfo.

Installation de Grep

Préparez la compilation de Grep :

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

Compilez le paquet :

make

Ce paquet dispose d'une suite de tests, réalisant plusieurs tests pour s'assurer que le programme a été construit correctement. Si vous décidez de le lancer, la commande suivante fera le nécessaire :

make check

Enfin, installez le paquet :

make install

Contenu de Grub

Le package Grub contient un chargeur de démarrage.

Programmes installés : grub, grub-install, grub-md5-crypt, grub-terminfo et mbchk

Dépendances d'installation de Grub

Grub dépend de Bash, Binutils, Coreutils, Diffutils, GCC, Glibc, Grep, Make, Ncurses, Sed.

Installation de Grub

Ce package est connu pour mal se comporter si vous changez les options d'optimisation par défaut (en incluant les options -march et -mcpu). Donc, si vous avez défini des variables d'environnement qui surchargent les optimisations pas défaut, telles que CFLAGS et CXXFLAGS, nous vous recommendons de supprimer cette initialisation lors de la construction de Grub.

Tout d'abord, corrigez un problème de compilation avec GCC-3.3.1 :

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

Maintenant, préparez la compilation de Grub :

./configure --prefix=/usr

Compilez le paquet :

make

Et installez-le :

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

Remplacez i386-pc avec le répertoire approprié pour votre matériel.

Le répertoire i386-pc contient aussi un certain nombre de fichiers *stage1_5, différents suivant les systèmes de fichiers. Jetez un oeil sur ceux disponibles et copiez les plus appropriés dans le répertoire /boot/grub. La plupart des personnes copieront les fichiers e2fs_stage1_5 et/ou reiserfs_stage1_5.

Contenu de Gzip

Le package Gzip contient des programmes pour compresser et décompresser des fichiers utilisant le codage Lempel-Ziv (LZ77).

Programmes installés : gunzip (lien vers gzip), gzexe, gzip, uncompress (lien vers gunzip), zcat (lien vers gzip), zcmp, zdiff, zegrep, zfgrep, zforce, zgrep, zless, zmore et znew

Dépendances d'installation de Gzip

Gzip dépend de Bash, Binutils, Coreutils, Diffutils, GCC, Glibc, Grep, Make, Sed.

Installation de Gzip

Préparez la compilation de Gzip :

./configure --prefix=/usr

Le programme gzexe dispose de l'emplacement de gzip codé en dur. Comme nous changerons plus tard l'emplacement de ce binaire, la commande suivante nous assure que le nouvel emplacement sera placé dans le binaire :

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

Compilez le paquet :

make

Installez le paquet :

make install

Et déplacez les programmes dans le répertoire /bin :

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

Contenu de Man

Man est un afficheur de pages man.

Programmes installés : apropos, makewhatis, man, man2dvi, man2html et whatis

Dépendances d'installation de Man

Man dépend de Bash, Binutils, Coreutils, Gawk, GCC, Glibc, Grep, Make, Sed.

Installation de Man

Nous allons faire quelques ajustements aux sources de Man.

Le premier correctif met en commentaire la ligne "MANPATH /usr/man" du fichier man.conf pour empêcher des résultats redondants lors de l'utilisation de programmes comme whatis :

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

Le second correctif ajoute l'option -R à la variable PAGER de façon à ce que les séquences d'échappement soient correctement gérées :

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

Le troisième et dernier correctif supprime un problème avec les pages man formatées sur plus de 80 colonnes utilisées avec les dernières versions de groff:

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

Maintenant, préparez la compilation de Man :

./configure -default -confdir=/etc

La signification des options de configure est la suivante :

• -default : Ceci indique au script configure de sélectionner un ensemble intéressant d'options par défaut. Par exemple, seulement les pages man anglaises, pas de catalogue de messages, man sans suid, gestion des pages man compressés, compresser les pages cat, créer les pages cat lorsque le répertoire approprié existe, suivre FHS en plaçant les pages cat sous /var/cache/man en supposant que ce répertoire existe.

• -confdir=/etc: Ceci indique au programme man de chercher le fichier de configuration man.conf dans le répertoire /etc.