Posté par gouttegd .
En réponse au message Kernel 4.0 et lfs.
Évalué à 2.
Dernière modification le 17 avril 2015 à 11:15.
Tu peux avoir un couplage plus fort, je n'ai pas remonté l'historique assez loin. Un noyau est forcément dépendant de ce que propose sa libc
Pas vraiment, non. Ce sont surtout les programmes en espace utilisateur qui dépendent beaucoup de ce que propose la libc.
Il y a plus de couplage entre la glibc et le reste de l’espace utilisateur, qu’entre le noyau et l’espace utilisateur (y compris la glibc).
Ça se traduit par le fait que mettre à jour la glibc est plus délicat que de mettre à jour le noyau : notamment, il n’est pas rare que de nombreux programmes en espace utilisateur doivent carrément être recompilés (pas forcément mis à jour, mais recompilés quand même) contre la nouvelle glibc pour fonctionner, alors qu’une mise à jour du noyau n’impose jamais de recompiler quoi que ce soit (ni la glibc, ni le reste de l’espace utilisateur).
[^] # Re: glibc non, systemd peut-être
Posté par gouttegd . En réponse au message Kernel 4.0 et lfs. Évalué à 2. Dernière modification le 17 avril 2015 à 11:15.
Pas vraiment, non. Ce sont surtout les programmes en espace utilisateur qui dépendent beaucoup de ce que propose la libc.
Il y a plus de couplage entre la glibc et le reste de l’espace utilisateur, qu’entre le noyau et l’espace utilisateur (y compris la glibc).
Ça se traduit par le fait que mettre à jour la glibc est plus délicat que de mettre à jour le noyau : notamment, il n’est pas rare que de nombreux programmes en espace utilisateur doivent carrément être recompilés (pas forcément mis à jour, mais recompilés quand même) contre la nouvelle glibc pour fonctionner, alors qu’une mise à jour du noyau n’impose jamais de recompiler quoi que ce soit (ni la glibc, ni le reste de l’espace utilisateur).