4 ms·

godot has a c++ toxicity issue to solve for elf/linux game binaries, I did report to them the issue, and indeed, they reasonably cannot do anything, only the gc

godot has a c++ toxicity issue to solve for elf/linux game binaries, I did report to them the issue, and indeed, they reasonably cannot do anything, only the gcc devs (glibc devs should be safe now) can do something (or godot would have to move to good and plain C, or similar). Game binaries should be a set of elf binaries statically loading (elf dt_needed) only libdl, namely with only dlopen/dlsym(tls safe)/dlclose symbols (with the oldest version as possible, probably 2.2.5) in the elf dynsym section except the other symbols from those very distributed binaries. The pb is the static gcc libstdc++ (and to a lesser extent the gcc static libgcc) does not libdl anything from the C runtime, or even worse could link to glibc internal symbols. All those very symbols, will end up in the elf dynsym section of the distributed binaries with the versions from the glibc used at link time. Namely, if a user wants to run on a older glibc distro those binaries, since glibc devs have a versioning frenzy, it won't even load (and the reasons are often more planned obsolescence than anything else). Some must not forget that static linking won't do unless a full elf loader is in linked in, since xcb/(wayland is static)/libasound(pulseaudio,pipewire,jack,whatever is hidden behind the alsa api)/libxkbcommon(-x11)/vulkan/(GL) libs will have to be loaded from system. Godot, as mitigation, pushes the devs to link with a very, VERY old, glibc (a decade?). It provides "containers" for "building" with an old glibc, and for the devs not using those containers, the documentation is clear about the age of the glibc to link with. The reality is gcc c++ was never meant for binary-only distribution, just never.

account42 4y ago
> Game binaries should be a set of elf binaries statically loading (elf dt_needed) only libdl, namely with only dlopen/dlsym(tls safe)/dlclose symbols (with the oldest version as possible, probably 2.2.5) in the elf dynsym section except the other symbols from those very distributed binaries. That is not a requirement at all. There is nothing wrong with linking against libc or other glibc libraries as long as you compile agianst the oldest version you want to support. Picking random version of glibc symbols makes no sense as they have absolutely no guarantee of being ABI-compatible, hence the different symbol versions. But if you WANT to dynamically load everying in glibc for whatever reason you can always create your own stub that provides those symbols and thunks the calls through function pointers that you can fill on startup with whaever logic you want and then statically link that stub so that all libc/whatever calls use your stub instead. > Godot, as mitigation, pushes the devs to link with a very, VERY old, glibc (a decade?). It provides "containers" for "building" with an old glibc, and for the devs not using those containers, the documentation is clear about the age of the glibc to link with. That is the best solution. Note that this does not mean that the users will be using an old unpatched glibc, just that the old interfaces will be used, which are still maintained in newer glibc versions.
- sylware 4y ago
  This is clearly what I was saying, missing out the "internal" glibc symbols issue due to the static libstdc++ (I have not got into the details of those symbols, they may be benign since lazy binding is the default), and I would rather favor a "less worse" than "best" terminology to be fair, since it is still causing issues with games, the major users of the binary-only distribution. We all know the only way to remove properly this "dirt", is too aim "explicit" (libdl) than "implicit" (elf dynsym section), which it seems to become the "normality" in many areas, like smp locking and high level syntax (was a target for python syntax). And that would open the road for alternative elf/C runtime... ofc glibc zealots won't like that at all, expect a lot of resistance and "mauvaise foi".

account42 4y ago

> Game binaries should be a set of elf binaries statically loading (elf dt_needed) only libdl, namely with only dlopen/dlsym(tls safe)/dlclose symbols (with the oldest version as possible, probably 2.2.5) in the elf dynsym section except the other symbols from those very distributed binaries. That is not a requirement at all. There is nothing wrong with linking against libc or other glibc libraries as long as you compile agianst the oldest version you want to support. Picking random version of glibc symbols makes no sense as they have absolutely no guarantee of being ABI-compatible, hence the different symbol versions. But if you WANT to dynamically load everying in glibc for whatever reason you can always create your own stub that provides those symbols and thunks the calls through function pointers that you can fill on startup with whaever logic you want and then statically link that stub so that all libc/whatever calls use your stub instead. > Godot, as mitigation, pushes the devs to link with a very, VERY old, glibc (a decade?). It provides "containers" for "building" with an old glibc, and for the devs not using those containers, the documentation is clear about the age of the glibc to link with. That is the best solution. Note that this does not mean that the users will be using an old unpatched glibc, just that the old interfaces will be used, which are still maintained in newer glibc versions.

sylware 4y ago
This is clearly what I was saying, missing out the "internal" glibc symbols issue due to the static libstdc++ (I have not got into the details of those symbols, they may be benign since lazy binding is the default), and I would rather favor a "less worse" than "best" terminology to be fair, since it is still causing issues with games, the major users of the binary-only distribution. We all know the only way to remove properly this "dirt", is too aim "explicit" (libdl) than "implicit" (elf dynsym section), which it seems to become the "normality" in many areas, like smp locking and high level syntax (was a target for python syntax). And that would open the road for alternative elf/C runtime... ofc glibc zealots won't like that at all, expect a lot of resistance and "mauvaise foi".