[charcircuit]

>in ways that can be subtly incompatible

There is much more value to be had in making glibc properly backward compatible so you can have a single one that can be used with everything than trying to make it so that you can swap everything around, creating extra complexity and compatibility risks.

[dspillett]

> […] in making glibc properly backward compatible […]

You could only do that going forward though, and would be stuck, at least for a time, with the historic versions that still need extra handling. In an ideal world that wouldn't be needed, but in an ideal world you'd not need multiple versions of glibc at all so we aren't there.

Support in the kernel means that it will work even if applied to old packages that for some other reason need a held-back version of glibc. As mentioned elsewhere it also gives the feature to #! directives in scripts too.

[roblabla]

How is that more valuable? It comes with two big pitfalls:

- It would still not allow downgrades to work properly

- It would cause glibc/ld.so to have a harder time adding new features, as they now need to worry about incompatible versions being used together

Meanwhile, having different ld.so has many good use-cases, like simplifying development of ld.so itself, allowing them to swapped during updates in ways that are safer, etc...

And the eBPF binfmt support is a rather simple, generic mechanism that is likely to have many other use-cases beyond ld.so. So it's overall a pretty good resolution to the issue?

[charcircuit]

>It would still not allow downgrades to work properly

If you really need this, then there are options like swapping the linker with an older version or making a hardcoded linker that now points to an older one.

>It would cause glibc/ld.so to have a harder time adding new features, as they now need to worry about incompatible versions being used together

Every language runtime has to care about not breaking compatibility with apps that have been released already. This is not a new or unique problem.