Subversion Repositories svn LFS-FR

Compare Revisions

Ignore whitespace Rev 102 → Rev 103

/branches/LFS-3_3b/lfs/chapter05/kernel-exp-headers.xml
1,33 → 1,33
<sect2>
<title>Pourquoi nous copions les en-têtes du noyau et pourquoi nous ne créons pas de liens</title>
 
<para>Auparavant, une pratique commune consistait à créer des liens symboliques
pour les répertoires /usr/include/linux et asm vers respectivement
/usr/src/linux/include/linux et asm. Ceci est une <emphasis>mauvaise</emphasis>
idée d'après cet extrait d'un envoi de Linus Torvalds sur la liste de diffusion
du noyau Linux:</para>
 
<screen>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
en-têtes du kernel 2.2.13, même si je n'ai pas lancé cette version du kernel 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.</screen>
 
<para>La partie importante là-dedans correspond au moment où il indique que les
en-têtes doivent être <emphasis>ceux avec lesquels glibc a été compilé</emphasis>.
Ces en-têtes doivent rester accessibles et en les copiant, nous nous assurons de
suivre ces recommandations. Notez aussi que tant que ces liens symboliques
ne sont pas créés, il est tout à fait correct d'avoir les sources du noyau sous
<filename>/usr/src/linux</filename>.</para>
 
</sect2>
<sect2>
<title>Pourquoi nous copions les en-têtes du noyau et pourquoi nous ne créons pas de liens</title>
 
<para>Auparavant, une pratique commune consistait à créer des liens symboliques
pour les répertoires /usr/include/linux et asm vers respectivement
/usr/src/linux/include/linux et asm. Ceci est une <emphasis>mauvaise</emphasis>
idée d'après cet extrait d'un envoi de Linus Torvalds sur la liste de diffusion
du noyau Linux:</para>
 
<screen>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
en-têtes du kernel 2.2.13, même si je n'ai pas lancé cette version du kernel 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.</screen>
 
<para>La partie importante là-dedans correspond au moment où il indique que les
en-têtes doivent être <emphasis>ceux avec lesquels glibc a été compilé</emphasis>.
Ces en-têtes doivent rester accessibles et en les copiant, nous nous assurons de
suivre ces recommandations. Notez aussi que tant que ces liens symboliques
ne sont pas créés, il est tout à fait correct d'avoir les sources du noyau sous
<filename>/usr/src/linux</filename>.</para>
 
</sect2>
/branches/LFS-3_3b/lfs/chapter05/grep.xml
1,13 → 1,12
<sect1 id="ch05-grep">
<title>Installer Grep-&grep-version;</title>
<?dbhtml filename="grep.html" dir="chapter05"?>
 
<screen>Estimation du temps de construction: &grep-time-static;
Estimation de l'espace disque requis: &grep-compsize-static;</screen>
 
&c5-grep-inst;
&aa-grep-desc;
&aa-grep-dep;
 
</sect1>
 
<sect1 id="ch05-grep">
<title>Installer Grep-&grep-version;</title>
<?dbhtml filename="grep.html" dir="chapter05"?>
 
<screen>Estimation du temps de construction: &grep-time-static;
Estimation de l'espace disque requis: &grep-compsize-static;</screen>
 
&c5-grep-inst;
&aa-grep-desc;
&aa-grep-dep;
 
</sect1>
/branches/LFS-3_3b/lfs/chapter05/kernel.xml
1,15 → 1,14
<sect1 id="ch05-kernel">
<title>Installer Linux Kernel-&kernel-version;</title>
<?dbhtml filename="kernel.html" dir="chapter05"?>
 
<screen>Estimation du temps de construction: &kernel-time-static;
Estimation de l'espace disque requis: &kernel-compsize-static;</screen>
 
&c5-kernel-inst;
&c5-kernel-exp;
&c5-kernel-exp-headers;
&aa-kernel-desc;
&aa-kernel-dep;
 
</sect1>
 
<sect1 id="ch05-kernel">
<title>Installer Linux Kernel-&kernel-version;</title>
<?dbhtml filename="kernel.html" dir="chapter05"?>
 
<screen>Estimation du temps de construction: &kernel-time-static;
Estimation de l'espace disque requis: &kernel-compsize-static;</screen>
 
&c5-kernel-inst;
&c5-kernel-exp;
&c5-kernel-exp-headers;
&aa-kernel-desc;
&aa-kernel-dep;
 
</sect1>
/branches/LFS-3_3b/lfs/chapter05/kernel-exp.xml
1,37 → 1,36
<sect2>
<title>Explication des commandes</title>
 
<para><userinput>make mrproper:</userinput> Ceci s'assure que l'arborescence
du noyau est parfaitement propre. Nous faisons ceci parce que l'équipe de
développement du noyau recommande que ceci soit fait avant <emphasis>chaque</emphasis>
compilation du noyau, et que nous ne devons pas supposer que l'arborescence
des sources soit propre après l'avoir déballé.</para>
 
<para><userinput>yes "" | make config:</userinput> Ceci exécute make config et
donne la réponse par défaut à toutes les questions que le script de
configuration pose à l'utilisateur (il fait ceci en se contentant de
transmettre l'équivalent de l'appui sur la touche Enter, qui accepte les
réponses par défaut Y et N aux questions). Nous ne configurons pas ici
le véritable noyau; nous n'avons besoin que d'un fichier de configuration
quelconque, pour pouvoir ensuite exécuter make dep qui créera de nouveaux
fichiers d'entête dans <filename>include/linux</filename>, comme version.h,
entre autres, dont nous aurons besoin plus tard dans chroot pour compiler
Glibc ainsi que d'autres packages.</para>
 
<para><userinput>make dep:</userinput> make dep vérifie les dépendances et crée
le fichier des dépendances. Nous n'avons pas vraiment besoin de la
vérification des dépendances, mais ce qui nous importe est que make dep
crée les fichiers susmentionnés dans <filename>include/linux</filename>,
dont nous aurons besoin plus tard.</para>
 
<para><userinput>mkdir $LFS/usr/include/asm</userinput>
and <userinput>cp include/asm/* $LFS/usr/include/asm</userinput>:
Ceci commande copie les fichiers d'entête assembleur du kernel dans
<filename>$LFS/usr/include/asm</filename>.</para>
 
<para><userinput>cp -R include/linux $LFS/usr/include</userinput>:
Cette commande copie les fichiers d'entête pour la cross-compilation du kernel dans
<filename>$LFS/usr/include</filename>.</para>
 
</sect2>
 
<sect2>
<title>Explication des commandes</title>
 
<para><userinput>make mrproper:</userinput> Ceci s'assure que l'arborescence
du noyau est parfaitement propre. Nous faisons ceci parce que l'équipe de
développement du noyau recommande que ceci soit fait avant <emphasis>chaque</emphasis>
compilation du noyau, et que nous ne devons pas supposer que l'arborescence
des sources soit propre après l'avoir déballé.</para>
 
<para><userinput>yes "" | make config:</userinput> Ceci exécute make config et
donne la réponse par défaut à toutes les questions que le script de
configuration pose à l'utilisateur (il fait ceci en se contentant de
transmettre l'équivalent de l'appui sur la touche Enter, qui accepte les
réponses par défaut Y et N aux questions). Nous ne configurons pas ici
le véritable noyau; nous n'avons besoin que d'un fichier de configuration
quelconque, pour pouvoir ensuite exécuter make dep qui créera de nouveaux
fichiers d'entête dans <filename>include/linux</filename>, comme version.h,
entre autres, dont nous aurons besoin plus tard dans chroot pour compiler
Glibc ainsi que d'autres packages.</para>
 
<para><userinput>make dep:</userinput> make dep vérifie les dépendances et crée
le fichier des dépendances. Nous n'avons pas vraiment besoin de la
vérification des dépendances, mais ce qui nous importe est que make dep
crée les fichiers susmentionnés dans <filename>include/linux</filename>,
dont nous aurons besoin plus tard.</para>
 
<para><userinput>mkdir $LFS/usr/include/asm</userinput>
and <userinput>cp include/asm/* $LFS/usr/include/asm</userinput>:
Ceci commande copie les fichiers d'entête assembleur du kernel dans
<filename>$LFS/usr/include/asm</filename>.</para>
 
<para><userinput>cp -R include/linux $LFS/usr/include</userinput>:
Cette commande copie les fichiers d'entête pour la cross-compilation du kernel dans
<filename>$LFS/usr/include</filename>.</para>
 
</sect2>
/branches/LFS-3_3b/lfs/appendixa/kernel-desc.xml
1,84 → 1,72
+<sect2><title>Contenu de kernel-&kernel-contversion;</title>
+
+<sect3><title>Support Files</title>
+<para>le noyau linux et les entêtes du noyau linux</para></sect3>
+
+
+<sect3><title>Descriptions</title>
+
+
+<sect4><title>noyau linux</title>
+
+
+<para>Le noyau de Linux est au coeur de chaque système Linux. C'est lui
+
+
+qui fait tourner Linux. Quand vous allumez votre ordinateur et démarrez
+
+
+un système Linux, la toute première partie de logiciel Linux qui est
+
+
+chargée est le noyau. Le noyau initialise les composants matériels du
+
+
+système comme les ports série, les ports parallèles, les cartes son,
+
+
+les cartes réseau, les contrôleurs IDE, les contrôleurs SCSI et beaucoup
+
+
+d'autres choses. En bref, le noyau rend le matériel disponible pour que
+
+
+le logiciel puisse fonctionner.</para></sect4>
+
+
+
+
+
+<sect4><title>entêtes du noyau linux</title>
+
+
+<para>Nous copions ces fichiers dans /usr/include/(linux,asm) lors du
+
+
+chapitre 5. Ils doivent correspondre à ceux avec lesquels glibc a été
+
+
+compilé et ne doivent <emphasis>pas</emphasis> être remplacé lors d'une
+
+
+mise à jour du kernel. Ils sont essentiels pour compiler un grand
+
+
+nombre de logiciels.</para></sect4>
+
+
+
+
+
+</sect3>
+
+
+
+
+
+</sect2>
+
+
+
+
+