Hacker News Reader

Comment by sylware | Hacker News Reader

Until godot devs don't forget the "-static-libgcc -static-libstdc++" compile/link options, should be fine, that linking with the oldest set of glibc libs as possible (I saw games carefully using the glibc from debian ubuntu 12.04).

I guess godot has proper vulkan->GL fallback.

What's now really missing is from sourceware binutils: fine grained control of the versions of the symbols to use while creating binaries. And then, robust game binaries would be much easier to produce: it would let the devs use the latest elf/linux distro and still produce compatible binaries with old elf/linux distros (easy planned obsolescence workaround) avoid the current massive mess (build an old glibc, and reconfigure the toolchain to use it for linking, PAIN).

View on HN

> 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.

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...

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.

Reply on news.ycombinator.com