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).<p>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.<p>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).<p>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.<p>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.<p>The reality is gcc c++ was never meant for binary-only distribution, just never.