[elFarto]

> What's now really missing is from sourceware binutils: fine grained control of the versions of the symbols to use while creating binaries.

I did actually prototype an idea for attempting to fix this. The tool would take a list of symbols from a text file and produce a (non-functioning) .so file that ld can link against. The newly created .so file can be injected in via an environment variable (LIBRARY_PATH iirc).

Since the list of symbols is just text, it's easily modified to contain only the one's that you want to target.

It's not a complicated tool to write, but there are some issues like how to reliably get ld to pick the correct .so file when you're overriding an existing on, LIBRARY_PATH is not 100% reliable. The other issue was if it's nessassary to recreate all the symbol types (like weak, etc..) exactly, I'm not sure exactly what's required for ld.

[sylware]

The text file would map simply a symbol to a version, to be overridden in the generated ELF binary (exe or SO).

That way, the game devs don't need to build the "old" SOs and reconfigure the toolchain to use them, which is unreasonable to ask them (but this is expected from game engine elf/linux devs like unity/unreal/godot/etc) and a MASSIVE PAIN to make work properly (exponentially proportional on the abstraction level of the game/engine build system).

While any "old" symbol version is not removed...

[sylware]

I correct myself: just overridding is shabby, once the linker has selected the the version of a symbol, it will pick the binary objecti(.o) where the this version is. And the semantic/dependency can vary from one version to another. See libc_start from glibc 2.34.

So I think we may have our solution to make the life of developers of binary-only distribution on elf/linux (for instance games) much better.

sourceware binutils ld need a "version selection" file which will define binary compatibility of the produced binaries.