It happens all the time: some c++ games are compiled for a shared libstdc++... which is not ABI compatible with the one from the steam runtime (this is well know issue:c++ ABI is HORRIBLE). Namely it breaks with the steam runtime shared libstdc++. I repeat: it has been happening ALL THE TIME IN THE LAST DECADE.

I usually ask their devs to use the '-static-libstdc++' gcc/clang option (and at the same time -static-libgcc), and this issue is gone... actually partially, because the static libstdc++ is not libdl-ing its system (module/version)s & (symbol/version)s (well, did not check if c++ gcc/clang devs did fix that) and this is a big problem too: the linker with use the most recent version of modules and symbols (and you cannot overide than unless properly using libdl with dlopen/dlsym/dlclose).

What is the problem with that: well, the game binaries will then refuse to load on system with glibc modules/symbols with "too old" versions... and I was hit hard with this: no more than 1.5 years... yep, this is filthy nasty. And yes, this is not limited to the static libstdc++, it encompasses the glibc modules too. Godot devs mitigate this by explicitely warning devs about this issue and provide some containers with a really old glibc in order to avoid too recent versions.

When you really look at this, I mean with a "final" perspective: the "right" way would be to eat the bullet, and I mean seriously: deprecate ELF DT_NEEDED (and static TLS). It means that if you want to get some services from the system shared objects, you must use dlopen/dlsym/dlclose (and deal with the versions). It would be those symbols will become hard defined in the ELF loader, like __get_tls_addr() for TLS.

We could manage to keep DT_NEEDED, but it means binutils ld MUST allow fine-grained version specification of modules(shared objects) and symbols... which it does not (or it was fixed very recently and I missed it, or I sucked and did miss it from the doc for years).