Stop hardcoding SOVERSION for stdlibs

[nalimilan]

Hardcoding versions is actually not needed as the build already creates symlinks from libXXX.so to libXXX.so.Y.Z. Since Julia does not always need a particular version, it is better to use the link which is created based on the one which was available at build time.
It also reduces the number of places to edit when upgrading to a new SOVERSION.
This was already the case for several libraries on Windows.

Fixes #40198.

[nalimilan]

I'm not sure why, but on Windows only libuv-2.dll is in the ZIP, not libuv.dll like for other libraries. So I skipped it on Windows and Mac to avoid breaking something (I couldn't check Mac).

[giordano]

I suspect this will make #40556 even more problematic

This was already the case for several libraries on Windows.

Probably mainly because Windows doesn't really have the concept of SONAME/SOVERSION.

[vtjnash]

This would seem to be the wrong name for these libraries, however, since the SONAME is the 'real' name and that includes the version number. We also can't test CI against all possible incompatible versions of a library, which is what an SONAME bump indicates.

[staticfloat]

I'm kind of against this; there's no guarantee that loading libfoo.so.3 when you expected libfoo.so.2 will work; it may in some cases, it may not in others, and when we ignore SONAMEs completely, we kine of throw away any ability to reject an improper library. I don't think it's worth it if installing a newer version of libfoo on your system suddenly causes Julia to stop working.

[nalimilan]

I don't think it's worth it if installing a newer version of libfoo on your system suddenly causes Julia to stop working.

AFAIK it shouldn't, as we always create symlinks from unversioned libXXX.so to libXXX.so.X.Y in $libdir/julia.

This change would only make a difference when passing USE_SYSTEM_XXX=1 explicitly anyway, which is only used by people who by definition prefer using the system library as much as possible. The idea is to get closer to how programs written in C typically work: they define version bounds for their dependencies, and as long as they match the build works and the SOVERSION is defined to be the one used at compile time. This is essential because a given program never uses all of the API of its dependencies, so it's quite common that it works with several SOVERSIONs.

[fingolfin]

But for those typical C programs, you do hardcode the SOVERSION; however, you can recompile them to support a newer SOVERSION. In the case of Julia, of course you recompile Julia itself. But then there are many many JLLs out there, which also contain binary code which may link against those standard libraries.

E.g. a ton link against GMP or MPFR. Now, right now, all of them are actually safe to use with any GMP 6.x version. But this may change: perhaps GMP 7 is released tomorrow and you want to use it on your system, and it happens to be "compatible enough" for Julia itself; but for some of those JLLs it may not be.

The result then will be segfaults.

So I think any change made here also needs to come with a plan to deal with JLLs that were built against specific versions of stdlibs.

[nalimilan]

One of the reasons why changing SOVERSIONs are so annoying is that MbedTLS breaks its API and bumps SOVERSION in minor releases, because its developers want to change a field or two in a struct. This isn't a sane versioning scheme. :-/ JuliaPackaging/Yggdrasil#4179 (comment) JuliaPackaging/Yggdrasil#4180 (comment)

[fingolfin]

Aye. But the solution for that can't be to just not track the SOVERSION. That'd be like "uncaught exception are annoying so let's not throw any exceptions anymore" :-)

[ViralBShah]

Is this ready to merge?

[giordano]

I don't think there is much agreement on this change.

[ViralBShah]

Is it ok to convert it to draft in that case?

[fingolfin]

I think this has no chance of being merged for reasons outlined in the discussion.