> You can try to do this with rpath of $ORIGIN. But then you'll probably still run into libc issues -.-
Linux (g)libc is sort of equivalent to the Win32 API on Windows so you are not expected to ship your own version just like you don't ship your own ntdll, user32, etc. Since glibc has good backwards compatibility the onlye libc issue you will run into is having to compile against the oldest version you want to support.
And the irony? It was someone on Unix who came up with the idea that when foo.c contains #include "bar.h", the same directory where foo.c resides will be searched for that header first, by default, before other places.
The idea of doing that for the DLL search in Windows could have been inspired by C.
So you are saying this is why Windows users universally complain about "DLL Hell", and Linux users don't? Or is this how MS finally fixed Windows DLL Hell? (Presuming Windows DLL Hell is, indeed, fixed; I wouldn't know.)
DLL hell is about program installers depositing some common libraries, like the MSVC redistributable run-time, into the system folder. So then every other application is using the most recently clobbered version of it instead of the one it came with.
GNU/Linux doesn't have DLL hell only to the extent that there is an entire binary distro with maintainers beavering to keep all of the dependencies straight so that every program that needs a certain shared library is maintained to need the same version of it as any other program.
You will experience shared library hell as soon as you have your own binary application that is not in the upstream distro, and it happens to depend on one of the lesser libraries that do not do symbol versioning like openssl, libbz2 and whatnot.
I've dealt with this plenty in more than one Linux embedded dayjob. In one case, I hacked an elaborate library searching system around dlopen() into such a program.
That's a minimal issue for games. You ship all dependencies with a start script that points LD_LIBRARY_PATH where you want and everything's fine. Or maybe even ship a flatpak. Issues for games come from other places.
If your program is a binary executable, and you have to script around its startup, that is ugly and unprofessional; it looks very bad for the underlying OS and its basic userland infrastructure that you have to do anything like that.
You can try to do this with rpath of $ORIGIN. But then you'll probably still run into libc issues -.-
Not hard to see why a lot of games focus on Windows and let wine/proton handle Linux.