The state of binary compatibility on Linux and how to address it

I don't understand why they don't just statically link their binaries. First, they said this:

> Even if you managed to statically link GLIBC—or used an alternative like musl—your application would be unable to load any dynamic libraries at runtime.

But then they immediately said they actually statically link all of their deps aside from libc.

> Instead, we take a different approach: statically linking everything we can.

If they're statically linking everything other than libc, then using musl or statically linking glibc will finish the job. Unless they have some need for loading share libs at runtime which they didn't already have linked into their binary (i.e. manual dlopen), this solves the portability problem on Linux.

What am I missing (assuming I know of the security implications of statically linked binaries -- which they didn't mention as a concern)?

Dynamic linking obviously has benefits or there would not be any incentive to build them or provide the capacity for them.

The problem is they also have problems which motivates people to statically link.

I remember back in the Amiga days when there were multiple libraries that provided file requesters. At one point I saw a unifying file requester library that implemented the interfaces of multiple others so that all requesters had the same look.

It's something that hasn't been done as far as I am aware on Linux. partially because of the problems with Linux dynamic libraries.

I think the answer isn't just static linking.

I think the solution is a commitment.

If you are going to make a dynamic library, commit to backwards compatibility. If you can't provide that, that's ok, but please statically link.

Perhaps making a library at a base level with a forever backwards compatible interface with a static version for breaking changes would help. That might allow for a blend of bug support and adding future features.