Due to GNU symbol versioning, it seems binaries which were linked with the glibc 2.34 would not run on systems running a glibc below or equal to 2.33.
The ELF->C runtime bridging code, in [S]crtX.o glibc objects, are now versioned and not backward compatible (seems to be orginated from guys from suse linux).
It seems that to make executable binaries robust over many glibc versions is to dynamically load it via libdl and not use C runtime "main" function but directly the x86_64 ABI. This specific part is very little work. But it would mean more work elsewhere since all used symbols from the glibc would have to be resolved with libdl dlopen/dlsym/dlclose (it did test with some of my project, even stdout must be resolved).
Ofc, the executable binaries should not be linked to glibc [S]crtX.o. Hopefully, for "shared libs", the DT_INIT_ARRAY/DT_FINI_ARRAY could be linked independently from the glibc, now versioned, ELF->C runtime bridging code for executable binaries.
Basically the steam-client would have to statically load only libdl, namely be the only library in the ELF DT_NEEDED sub-section (ELF dynamic section).
The steam-runtime is impacted the same way. I don't know if it can survive this in its current state. It would mean "modern" games would have to assume their "above video game core" dependencies themselves.
All that would be a significant amount of work, but, as a positive note, should allow alternative C-runtimes to run steam and games.
Due to GNU symbol versioning, it seems binaries which were linked with the glibc 2.34 would not run on systems running a glibc below or equal to 2.33.
The ELF->C runtime bridging code, in [S]crtX.o glibc objects, are now versioned and not backward compatible (seems to be orginated from guys from suse linux).
It seems that to make executable binaries robust over many glibc versions is to dynamically load it via libdl and not use C runtime "main" function but directly the x86_64 ABI. This specific part is very little work. But it would mean more work elsewhere since all used symbols from the glibc would have to be resolved with libdl dlopen/dlsym/dlclose (it did test with some of my project, even stdout must be resolved).
Ofc, the executable binaries should not be linked to glibc [S]crtX.o. Hopefully, for "shared libs", the DT_INIT_ARRAY/DT_FINI_ARRAY could be linked independently from the glibc, now versioned, ELF->C runtime bridging code for executable binaries.
Basically the steam-client would have to statically load only libdl, namely be the only library in the ELF DT_NEEDED sub-section (ELF dynamic section).
The steam-runtime is impacted the same way. I don't know if it can survive this in its current state. It would mean "modern" games would have to assume their "above video game core" dependencies themselves.
All that would be a significant amount of work, but, as a positive note, should allow alternative C-runtimes to run steam and games.
Ofc, there would be many issues to be ironed out.