> Y'a-t-il dans l'assistance une moule (barbu(e) et chevelu(e) comme il se doit) qui pourrait éclairer ma lanterne ? Me remettre dans le droit chemin de l'obéissance stricte du dogme ?
Quand tu compiles ta glibc, elle utilise les entêtes de la version installé du noyau : les entêtes dans /usr/src/linux/include (sauf si tu as utilisé le paramètre "--with-headers" lors du "./configure") sont utilisés. Certaines distributions incluent donc un lien /usr/include/asm qui pointe vers /usr/src/linux/include/asm (et aussi un lien /usr/include/linux qui pointe vers /usr/src/linux/include/linux).
Or si tu installes un nouveau noyau dans /usr/src/linux, le nouveau contenu de /usr/src/linux/include/{asm,linux} ne correspond pas forcément à l'ancien contenu : des structures ont pu radicalement changer. Ainsi, si tu compiles un programme sur ton système, il utiliseras les nouvelles structures avec les appels systèmes de la libraries C qui s'attendent à recevoir l'ancienne version de la structure : évidemment, ce n'est pas correct.
La solution ? Normalement, une distribution bien faite doit copier les entêtes du noyau utilisés pour la compilation de la glibc dans /usr/include : ainsi, sur une architecture ix86, le lien /usr/include/asm doit être un dossier ou un lien qui pointe sur le dossier /usr/include/asm-i386 (dossier qui contient une copie des entêtes du noyau linux utilisé lors de la compilation de la glibc). De même pour /usr/include/linux qui doit être un dossier et non pas un lien vers /usr/src/include/linux.
Pour information, Linux Slackware (depuis la version 9.x au moins) n'est pas concernée par ce problème dans la mesure ou les entêtes utilisés pour la compilation de la glibc sont regroupés dans leur propres paquetage (kernel-headers) et ils sont installés dans /usr/include sans aucun lien symbolique avec /usr/src/linux/include.
# Re: Compiler son kernel dans /usr/src/linux, c'est mal ?
Posté par kapouik . En réponse au journal Compiler son kernel dans /usr/src/linux, c'est mal ?. Évalué à 5.
Quand tu compiles ta glibc, elle utilise les entêtes de la version installé du noyau : les entêtes dans /usr/src/linux/include (sauf si tu as utilisé le paramètre "--with-headers" lors du "./configure") sont utilisés. Certaines distributions incluent donc un lien /usr/include/asm qui pointe vers /usr/src/linux/include/asm (et aussi un lien /usr/include/linux qui pointe vers /usr/src/linux/include/linux).
Or si tu installes un nouveau noyau dans /usr/src/linux, le nouveau contenu de /usr/src/linux/include/{asm,linux} ne correspond pas forcément à l'ancien contenu : des structures ont pu radicalement changer. Ainsi, si tu compiles un programme sur ton système, il utiliseras les nouvelles structures avec les appels systèmes de la libraries C qui s'attendent à recevoir l'ancienne version de la structure : évidemment, ce n'est pas correct.
La solution ? Normalement, une distribution bien faite doit copier les entêtes du noyau utilisés pour la compilation de la glibc dans /usr/include : ainsi, sur une architecture ix86, le lien /usr/include/asm doit être un dossier ou un lien qui pointe sur le dossier /usr/include/asm-i386 (dossier qui contient une copie des entêtes du noyau linux utilisé lors de la compilation de la glibc). De même pour /usr/include/linux qui doit être un dossier et non pas un lien vers /usr/src/include/linux.
Pour information, Linux Slackware (depuis la version 9.x au moins) n'est pas concernée par ce problème dans la mesure ou les entêtes utilisés pour la compilation de la glibc sont regroupés dans leur propres paquetage (kernel-headers) et ils sont installés dans /usr/include sans aucun lien symbolique avec /usr/src/linux/include.