| 1 |
Merci Thomas d'avoir pris le temps d'expliquer tout ça très clairement |
| 2 |
:) |
| 3 |
C'était très intéressant. |
| 4 |
|
| 5 |
|
| 6 |
Nico |
| 7 |
|
| 8 |
Le lun 09/02/2004 à 22:59, Thomas de Grenier de Latour a écrit : |
| 9 |
|
| 10 |
> On Mon, 09 Feb 2004 22:10:28 +0100 |
| 11 |
> Nicolas ANTONIAZZI <the.bestel@××××.fr> wrote: |
| 12 |
> |
| 13 |
> > |
| 14 |
> > J'ai lu un message de Linus Torvalds qui disait que /usr/src/linux |
| 15 |
> > devait pointer vers les sources du noyau qui avait servi à compiler |
| 16 |
> > glibc et non celui qui sert de noyau de boot. |
| 17 |
> |
| 18 |
> Barf, c'est un vieux troll... |
| 19 |
> |
| 20 |
> En fait, ce sur quoi il a fondamentalement insisté, c'était justement |
| 21 |
> sur ce que les headers system (ceux pour compiler la glibc) ne devaient |
| 22 |
> pas être confondu avec les headers du noyau en cours d'utilisation |
| 23 |
> (dont on ne se sert plus que pour compiler des modules). Il se trouve |
| 24 |
> qu'à l'époque, certaines distribs populaires avaient les sources de leur |
| 25 |
> noyau standard dans /usr/src/linux, et fesaient pointer |
| 26 |
> /usr/include/linux sur /usr/src/linux/include. Elles fesaient en gros |
| 27 |
> l'hypothèse que /usr/src/linux ne changerait pas de contenu. Et puis |
| 28 |
> elles ont oublié, commencé à permettre de choisir parmis différents |
| 29 |
> noyaux, et ça a foutu la merde parceque les gens se retrouvaient à |
| 30 |
> compiler des programmes avec des headers system plus récents que ceux |
| 31 |
> qui avaient servi à la glibc, et patatra. |
| 32 |
> |
| 33 |
> Donc il a dit, en interprétant à peine : faites un vrai répertoire |
| 34 |
> /usr/include/linux, n'y touchez jamais (car en ces temps là on ne |
| 35 |
> s'amusaient pas à recompiler si souvent la glibc, je rappelle que je |
| 36 |
> parle du temps où des gens utilisaient des rpm, tout ça quoi), et si |
| 37 |
> vous tenez à avoir un/usr/src/linux parceque certains programmes |
| 38 |
> incluent ce path, alors faites en un lien vers ce répértoire. Quand aux |
| 39 |
> sources noyau, mettez les comme des grand dans votre homedir, et puis |
| 40 |
> tiens même compilez le le en tant que simple utilisateur et faites juste |
| 41 |
> un sudo pour l'install'. |
| 42 |
> |
| 43 |
> Il se trouve que la pratique n'a pas suivit à la lettre ses |
| 44 |
> recommandations, les gens étant habitués à compiler leur noyau en root |
| 45 |
> dans /usr/src/linux, et les modules externes étant habitués à utiliser |
| 46 |
> ce path. Donc /usr/src/linux est resté comme le path de sources du |
| 47 |
> noyau (en vrai répertoire ou en lien vers un linux-version selon les |
| 48 |
> distribs). Sous Gentoo, ça nous arrange bien, parcequ'on avait besoin |
| 49 |
> d'un tel chemin standard: on ne peut pas se référer au nom du noyau en |
| 50 |
> cours d'utilisation pour choisir le chemin des sources du noyau pour |
| 51 |
> lequel compiler des paquet drivers, parcequ'il est parfois indispensable |
| 52 |
> de faire un emerge de tels drivers avant justement de pouvoir faire |
| 53 |
> tourner le dit noyau. Le lien /usr/src/linux sert donc de cible standard |
| 54 |
> pour les drivers, ce qui règle le problème. |
| 55 |
> |
| 56 |
> Par contre, le fait que les headers system ne devaient pas être |
| 57 |
> confondus avec ceux du noyau courant a été bien compris, et maintenant |
| 58 |
> les programmes et la glibc se réferent uniquement à /usr/include/linux, |
| 59 |
> qui est un vrai répertoire, indépendant des aléas du noyau. C'était ça |
| 60 |
> qui était fondamental, donc tout est bien. La preuve, ça marche. |
| 61 |
> |
| 62 |
> En espérant ne pas avoir trop déformé l'histoire, |
Archives