> It doesn't allow you to install minor versions of the same library at the same time (thats how you end up with all these 1.so, 2.so)
Minor versions should be ABI-compatible so you should only need the newer of the two. For ABI-incompatible changes, a different SONAME is appropriate, though the convention would be .so.0 -> .so.1 etc.
> So if you want a binary to work across multiple distributions, you can build it on a really old CentOS and if you are lucky it will work, but I have no trust in this.
As far as glibc or other libraries that take ABI stability seriously go, this does work.
> Forward-compatibility is not really considered, where you update your libraries and your existing app becomes more powerful.
Symbol versioning does not prevent you from updating the implementation of old symbol versions in a compatible way.
> The dynamic linker doesn't allow you to load two different library versions at the same time (without a lot of contortions). You would think you could do `dlopen` and `dlsym` on two different `.so` files, and then just have separate function pointers to each version's functions. But the linker loves to load all the symbols into a global namespace for some reason.
Having an option to use a separate linking table for specific dlopen calls would be useful, yes.
> Symbol versioning does not prevent you from updating the implementation of old symbol versions in a compatible way.
As I understand the problem is that if application is compatible with both version X and X+1, then there is no way to compile binary that would preferentially use X+1 when available but also work with X.
So applications can not reap the benefits of new version without dropping support with old version.
What benefits are you talking about. In general benefits not related to the ABI will be gained when updating glibc. For benefits related to the ABI the gains are probably so small that conditionally using the new ABI is likely not worth it in almost all cases.
Libraries loaded with RTLD_LOCAL will still have their symbols resolved against those from already loaded libraries as well as the main executable. Looks like there is dlmopen() in glibc since ~2005 though and there is libcapsule [0] which makes it actually usabel - neat.
Minor versions should be ABI-compatible so you should only need the newer of the two. For ABI-incompatible changes, a different SONAME is appropriate, though the convention would be .so.0 -> .so.1 etc.
> So if you want a binary to work across multiple distributions, you can build it on a really old CentOS and if you are lucky it will work, but I have no trust in this.
As far as glibc or other libraries that take ABI stability seriously go, this does work.
> Forward-compatibility is not really considered, where you update your libraries and your existing app becomes more powerful.
Symbol versioning does not prevent you from updating the implementation of old symbol versions in a compatible way.
> The dynamic linker doesn't allow you to load two different library versions at the same time (without a lot of contortions). You would think you could do `dlopen` and `dlsym` on two different `.so` files, and then just have separate function pointers to each version's functions. But the linker loves to load all the symbols into a global namespace for some reason.
Having an option to use a separate linking table for specific dlopen calls would be useful, yes.