4 ms·

They all package different versions of the shared libs...

andy_ppp 6y ago
Why are shared libs so unstable? I thought the point of library code was that it was stable and reusable... maybe all these libraries are just too big and people should be including the source inside their apps instead?
- foobar_ 6y ago
  I don't think any package manager does that. That would definitely be useful. Compile and ship binaries down to libc and use binaries on any GNU / Linux System. I don't see why as long as you output an ELF file an App can't run. Maybe AppImage does that.
wahern 6y ago
glibc has really good backward compatibility. But, yeah, few other libraries even bother, let alone make a serious attempt at this. One of the major exceptions is libvirt, which promised 100% backward compatibility from day 1. Here's a great overview (2011) of how they accomplish that: https://www.berrange.com/posts/2011/01/13/versioning-in-the-libvirt-library/ https://www.berrange.com/posts/2011/01/13/versioning-in-the-... Note that it wasn't until GCC 10 (2020) that you could implement ELF symbol versioning without using an ugly inline asm hack in your function definition. From the GCC 10 release notes at https://gcc.gnu.org/gcc-10/changes.html https://gcc.gnu.org/gcc-10/changes.html: > The symver attribute can be used to bind symbols to specific version nodes on ELF platforms. This is preferred to using inline assembly with GNU as symver directive because the latter is not compatible with link-time optimizations. In combination with confusion around the differences between file suffix versioning, soname versioning, and symbol versioning, it's not surprising few developers even attempt to get this right. OTOH, most ABI breakages are because of dumb mistakes early on or gratuitous changes to the API. If you commit to API stability from the beginning, then ABI stability can and will come more naturally, at least for C code. Versioning of any sort becomes less complicated and even less important.[1] C++ is different because of how heavily header-defined templates are used these days. [1] In other words, if you think API and ABI stability is principally a question of versioning, such as semantic versioning, you're doing it wrong. Commit to 100% backward compatibility at the API level and the answers to most of your design dilemmas become obvious. With the reduced cognitive burden, minding ABI compatibility becomes easier.
- ur-whale 6y ago
  > glibc has really good backward compatibility. That has really not been my experience. I've consistently hit problem with older software not running because it detected an incompatible version of GLIBC.
  - wahern 6y ago
    Not running or not compiling? I've often had issues with compiling, either because of unwarranted assumptions in the third-party projects or because glibc made changes to their absurdly complex naming and feature gating hacks in their header files. But glibc uses symbol versioning so even if the prototype of function foo changes, older software built against version X.Y should still link to fooX.Y at runtime. I don't follow glibc closely enough to know how many times they've accidentally broken things, though. I'm sure it's happened. More complex runtime behaviors, like with the DNS resolver, are definitely common, but usually it's debatable whether glibc is fairly blameworthy.
  - megous 6y ago
    Well, it's backward compatibility, not forward one, so you can't compile on Arch Linux and run on Red Hat 4. But you can other way round.

Why are shared libs so unstable? I thought the point of library code was that it was stable and reusable... maybe all these libraries are just too big and people should be including the source inside their apps instead?

foobar_ 6y ago
I don't think any package manager does that. That would definitely be useful. Compile and ship binaries down to libc and use binaries on any GNU / Linux System. I don't see why as long as you output an ELF file an App can't run. Maybe AppImage does that.

wahern 6y ago

glibc has really good backward compatibility. But, yeah, few other libraries even bother, let alone make a serious attempt at this. One of the major exceptions is libvirt, which promised 100% backward compatibility from day 1. Here's a great overview (2011) of how they accomplish that: https://www.berrange.com/posts/2011/01/13/versioning-in-the-libvirt-library/ https://www.berrange.com/posts/2011/01/13/versioning-in-the-... Note that it wasn't until GCC 10 (2020) that you could implement ELF symbol versioning without using an ugly inline asm hack in your function definition. From the GCC 10 release notes at https://gcc.gnu.org/gcc-10/changes.html https://gcc.gnu.org/gcc-10/changes.html: > The symver attribute can be used to bind symbols to specific version nodes on ELF platforms. This is preferred to using inline assembly with GNU as symver directive because the latter is not compatible with link-time optimizations. In combination with confusion around the differences between file suffix versioning, soname versioning, and symbol versioning, it's not surprising few developers even attempt to get this right. OTOH, most ABI breakages are because of dumb mistakes early on or gratuitous changes to the API. If you commit to API stability from the beginning, then ABI stability can and will come more naturally, at least for C code. Versioning of any sort becomes less complicated and even less important.[1] C++ is different because of how heavily header-defined templates are used these days. [1] In other words, if you think API and ABI stability is principally a question of versioning, such as semantic versioning, you're doing it wrong. Commit to 100% backward compatibility at the API level and the answers to most of your design dilemmas become obvious. With the reduced cognitive burden, minding ABI compatibility becomes easier.

ur-whale 6y ago
> glibc has really good backward compatibility. That has really not been my experience. I've consistently hit problem with older software not running because it detected an incompatible version of GLIBC.
- wahern 6y ago
  Not running or not compiling? I've often had issues with compiling, either because of unwarranted assumptions in the third-party projects or because glibc made changes to their absurdly complex naming and feature gating hacks in their header files. But glibc uses symbol versioning so even if the prototype of function foo changes, older software built against version X.Y should still link to fooX.Y at runtime. I don't follow glibc closely enough to know how many times they've accidentally broken things, though. I'm sure it's happened. More complex runtime behaviors, like with the DNS resolver, are definitely common, but usually it's debatable whether glibc is fairly blameworthy.
- megous 6y ago
  Well, it's backward compatibility, not forward one, so you can't compile on Arch Linux and run on Red Hat 4. But you can other way round.