Avec musl, l'ABI est bien moins souvent cassée. C'est à glibc qu'il faut casser les pieds si on veut une ABI stable, mais moi je persiste à dire que ceux qui veulent toujours et encore une ABI stable pensent résoudre un problème qui n'existe pas. Si on change pas les comportements et qu'on nettoie pas les bibliothèque, on se retrouve avec une usine à gaz ingérable.
Le versioning des bibliothèques résout ce problème et je me souviens dans le passé avoir du installer une version spécifique de libstdc++ (fournie avec GCC) plus ancienne (.5 ou quelque chose) pour faire tourner mon jeu préféré de l'époque : ut2004. Mais à part ça, il me fallait aussi SDL 1.2 et autres bibliothèques totalement obsolètes.
Vouloir une ABI stable c'est se cantonner au passé, sinon il suffit que les packagers fournissent des versions plus anciennes et le problème est résolu. Rien ne t'empêche d'avoir :
/usr/lib/libc.so.4
/usr/lib/libc.so.5
/usr/lib/libc.so.6
Merci le versioning, merci ELF.
git is great because linus did it, mercurial is better because he didn't
Ca résoud pas toujours tout. Des fois, on compile statiquement, on envoie sur le système cible, et là:
Oui mis non, le problème évoqué ici est l'inverse : porter un nouveau soft sur une vielle machine. L'intérêt d'une abi stable est d'utiliser une vieux soft sur une vielle machine
# ABi et API
Posté par ǝpɐןƃu∀ nǝıɥʇʇɐW-ǝɹɹǝıԀ (site web personnel) . Évalué à 4.
Est-ce vraiment utile pour des codes ouverts de disposer d’une ABI stable ? Si je comprends bien, il suffit de recompiler…
——->[]
« IRAFURORBREVISESTANIMUMREGEQUINISIPARETIMPERAT » — Odes — Horace
[^] # Re: ABi et API
Posté par Pinaraf . Évalué à 5.
Dans le cas présent, même pas. Si une appli lit la table des symboles elle-même, il faut patcher le code.
# Le problème c'est glibc
Posté par David Demelier (site web personnel) . Évalué à 10.
Avec musl, l'ABI est bien moins souvent cassée. C'est à glibc qu'il faut casser les pieds si on veut une ABI stable, mais moi je persiste à dire que ceux qui veulent toujours et encore une ABI stable pensent résoudre un problème qui n'existe pas. Si on change pas les comportements et qu'on nettoie pas les bibliothèque, on se retrouve avec une usine à gaz ingérable.
Le versioning des bibliothèques résout ce problème et je me souviens dans le passé avoir du installer une version spécifique de libstdc++ (fournie avec GCC) plus ancienne (.5 ou quelque chose) pour faire tourner mon jeu préféré de l'époque : ut2004. Mais à part ça, il me fallait aussi SDL 1.2 et autres bibliothèques totalement obsolètes.
Vouloir une ABI stable c'est se cantonner au passé, sinon il suffit que les packagers fournissent des versions plus anciennes et le problème est résolu. Rien ne t'empêche d'avoir :
Merci le versioning, merci ELF.
git is great because linus did it, mercurial is better because he didn't
# L'ABI ne fait pas le moine
Posté par devnewton 🍺 (site web personnel) . Évalué à 9.
Si certains aiment l'enfer des DLLs, car Satan l'hABIte, je pense qu'il vaut mieux :
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: L'ABI ne fait pas le moine
Posté par octane . Évalué à 2.
Ca résoud pas toujours tout. Des fois, on compile statiquement, on envoie sur le système cible, et là:
FATAL: kernel too old
et pouf.
[^] # Re: L'ABI ne fait pas le moine
Posté par purplepsycho . Évalué à 1.
Oui mis non, le problème évoqué ici est l'inverse : porter un nouveau soft sur une vielle machine. L'intérêt d'une abi stable est d'utiliser une vieux soft sur une vielle machine
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.