Re: compil de différents noyaux et dépendances vis à vis de /usr/include/linux

[pfml <pfml@imecom.net>]

Sylvain Sauvage a écrit :
> Mercredi 20 septembre 2006, 12:42:17 CEST, pfml a écrit :
>   
> > bonjour,
> >     
>
> 'jour,
>  
>   
> > je me pose la question suivante: est ce qu'une arbo des sources du
> > noyau est indépendante des include "système" de la machine de build ?
> > (je suppose que oui évidemment mais des erreurs de compilation me font 
> > douter du contraire)
> >     
>
>   Les sources du noyau sont indépendantes de /usr/include.
>   
ça me rassure
>   
> > je suis avec une kubuntu et je veux compiler des noyaux 2.6 et 2.4
> > la compilation du noyau s'effectue au sein de l'arbo des sources en 
> > utilisant éventuellement les .h du compilo bien sur (les seuls fichiers 
> > en dehors de l'arbo)
> >     
>
>   La compilation est faite avec -nostdinc, les include du compilateur (et
> du noyau évidemment) sont ajoutées après.
>   
ok
>   
> > sur mon système, /usr/include/linux contient les .h installés par
> > kubuntu je suppose qu'il corresponde à mon noyau std et sont présent
> > pour les applis "user" qui ont besoin des .h du système
> >     
>
>   Actuellement, pour une Sid, ils correspondent à un noyau 2.6.17.10
> (paquet linux-kernel-headers, à ne pas confondre avec linux-headers, qui,
>  lui, correspond au noyau installé et sert à compiler des modules).
>
>   
> > après avoir compiler un noyau, j'effectue un
> >     find . | xargs grep /usr/include/linux
> >     
>
>   (rgrep fonctionne très bien aussi.)
>
>   
> > et il me trouve quelques fichiers comme ./scripts/basic/.fixdep.cmd
> >
> > la compil du noyau semble faire référence à /usr/include/linux/limits.h 
> > /usr/include/linux/errno.h
> >
> > ce que j'en déduis (certainement à tort) c'est que la compil d'un noyau 
> > 2.x va (peut être) utiliser les errno.h/limits.h dépendants de la 
> > machine de build
> > * soit limits.h/errno.h n'ont pas changé depuis "longtemps" et c'est 
> > acceptable
> > * soit je me plante complètement
> >     
>
>   Solution n° 3 : la compilation va les utiliser pour des outils annexes,
> des _scripts_, comme fixdep. Remarque aussi que gcc est lui-même compilé
> avec d'autres en-têtes que ceux du noyau que tu compiles, mais,
> contrairement à fixdep, il est un peu gros pour être recompilé à chaque
> fois ;o)
>   
ok
>   
> > ma "vraie" question en formulation plus simple
> > sur une machine de build, on peut compiler des noyaux 2.4.x et 2.6.x 
> > sans avoir à bidouiller les fichiers sous /usr/include/... ?
> >     
>
>   Oui. Tu peux même faire de la compilation pour une machine totalement
> différente de celle sur laquelle tu compiles (cross-compilation). Et
> c'est heureux, sinon on a un problème de poule et d'œuf.
>
>   (Oui, dans l'absolu, car il faut faire attention à la version de gcc :
> de très vieux noyaux n'aiment pas être compilés par des gcc très récents.)
>
>   
ben là, chapeau : c'est pile les réponses claires que j'attendais

merci !