Yep, for their steam client (and games), they should craft 'correct' ELF64 binaries for broad "linux" distro support and long term support (which would not require the linux user namespace, like tons of "correct" games out there, for instance most, but not all, godot4 based games). Namely, _all_ the ELF64 binaries should statically load _only_ common glibc libs and that with an "old" glibc ABI version (I would target at least ~10 years, but there is no reason anymore to push forward the glibc version for this type of software, namely the next time they change something about the glibc requirement would be... no glibc is required anymore because we did manage to get rid of ELF for exe and dynamic lib finally).
Then, all their ELF64 binaries which require system interface shared libs would dynamically load them (libdl, dlopen/dlsym/dlclose). The system interface shared libs are libasound (the in-process audio software mixer + interface to external audio mixer daemons), the vulkan loader, and the legacy x11 client libs (with a properly tested wayland->x11 fallback).
All the remaining software should be statically loaded then, which probably mean symbol name customization to avoid collision (wayland/libxkbcommon, libz, libcurl, libressl/libopenssls, etc...)
All this does imply the usage of the following ubiquitous compiling/linking options (gcc and probably clang, tinycc? cproc/qbe? scc?): '-static-libgcc -static-libstdc++ -Wl,--enable-new-dtags' (libgcc_s is private to the distro, additionnaly it has been proven again and again its ABI cannot be trusted in the last decade+, and libstdc++ is private to the application as the distro could use another version of the shared c++ runtime, another vendor, or even statically link it to avoid c++ ABI hell... or none).
For linux native games, they should have a program (a bit like the 'verified' one which is limited to the steamdeck and steamos) with automated tools to statically verify some of this 'correctness' (the static loading of shared libs, the ELF dtags like DT_RUNPATH instead fo DT_RPATH, the glibc ABI version) of the ELF64 binaries and guide the game devs on how to fix them. The hard part is the runtime test, basically the dynamic loading of system interface shared libs (with a bit of fallback, for instance wayland->x11).
The really hard part for game/game engine devs is actually 3D programming, which must be super conservative, that to satisfy most 3D driver vendors [and versions...].
Ofc, valve should work with the devs of the major game engines in order to achieve the broadest distro support on the maximum amount of time following those guidelines (godot4/unity/UE/etc).
(I don't talk about the ELF64 relocations handled by the linux kernel and the glibc elf loader which should be stable for forever now).
If things ever move again, it would be first for the removal of ELF for a super simple exe and dynamic libs format which our modern hardware actitectures can handle roughly without kernel help: one log2 aligned segment, one entry point offset for exes, one 'userland' syscall number resolution function offset for dynamic libraries (guarded by hardware try-lock logic, which would guard an in-process 'loaded dynamic lib' tracker too: yep no more external ELF loader). Oh and of course the removal of x11. (I use such simple format for many of my personal projects).
I talked about mostly C/c++ but it is the same ABI requirement for any other compiled language mostly for dynamic loading of ELF system interface shared libs.
(the interface for joypads is the input event devices from the linux kernel).
If am talking about "linux" here, but this applies to any OS.
And maybe in the future we will get a simple hardware programming standard for all GPUs with a shader standard ISA , and then most of the driver complexity will be gone.
Then, all their ELF64 binaries which require system interface shared libs would dynamically load them (libdl, dlopen/dlsym/dlclose). The system interface shared libs are libasound (the in-process audio software mixer + interface to external audio mixer daemons), the vulkan loader, and the legacy x11 client libs (with a properly tested wayland->x11 fallback).
All the remaining software should be statically loaded then, which probably mean symbol name customization to avoid collision (wayland/libxkbcommon, libz, libcurl, libressl/libopenssls, etc...)
All this does imply the usage of the following ubiquitous compiling/linking options (gcc and probably clang, tinycc? cproc/qbe? scc?): '-static-libgcc -static-libstdc++ -Wl,--enable-new-dtags' (libgcc_s is private to the distro, additionnaly it has been proven again and again its ABI cannot be trusted in the last decade+, and libstdc++ is private to the application as the distro could use another version of the shared c++ runtime, another vendor, or even statically link it to avoid c++ ABI hell... or none).
For linux native games, they should have a program (a bit like the 'verified' one which is limited to the steamdeck and steamos) with automated tools to statically verify some of this 'correctness' (the static loading of shared libs, the ELF dtags like DT_RUNPATH instead fo DT_RPATH, the glibc ABI version) of the ELF64 binaries and guide the game devs on how to fix them. The hard part is the runtime test, basically the dynamic loading of system interface shared libs (with a bit of fallback, for instance wayland->x11).
The really hard part for game/game engine devs is actually 3D programming, which must be super conservative, that to satisfy most 3D driver vendors [and versions...].
Ofc, valve should work with the devs of the major game engines in order to achieve the broadest distro support on the maximum amount of time following those guidelines (godot4/unity/UE/etc).
(I don't talk about the ELF64 relocations handled by the linux kernel and the glibc elf loader which should be stable for forever now).
If things ever move again, it would be first for the removal of ELF for a super simple exe and dynamic libs format which our modern hardware actitectures can handle roughly without kernel help: one log2 aligned segment, one entry point offset for exes, one 'userland' syscall number resolution function offset for dynamic libraries (guarded by hardware try-lock logic, which would guard an in-process 'loaded dynamic lib' tracker too: yep no more external ELF loader). Oh and of course the removal of x11. (I use such simple format for many of my personal projects).
I talked about mostly C/c++ but it is the same ABI requirement for any other compiled language mostly for dynamic loading of ELF system interface shared libs.
(the interface for joypads is the input event devices from the linux kernel).
If am talking about "linux" here, but this applies to any OS.
And maybe in the future we will get a simple hardware programming standard for all GPUs with a shader standard ISA , and then most of the driver complexity will be gone.