View attachment 8461063
Windows having its .DLLS in the SAME folder as the application made software preservation SO much easier.
Linux and its idea of moving everything to /lib/ conflicting with others makes it SO fucking hard to port stuff and this is ONE of the reasons why Linux is LESS maintained software wise.
I love linux, I want it to do better, But this shit does NOT help anyone.
Dynamic libraries sucking massive dick on Linux is a function of Unix-style system-wide dynamic libraries interacting very poorly with the fractured nature of its ecosystem. This has been
the big problem with making software for Linux for decades, Linus has talked about it, everyone has talked about it, this is the entire reason container formats like Flatpak exist. You cannot ship binary-only software on Linux and expect it to work reliably across distros. Not helping this is how Glibc is also notorious for breaking ABI between versions.
You know they've had portable tarballs for programs on linux for a long time right?
The big bug bear with those is always Glibc, because the design of Posix makes it very, very hard to not link against your system’s libc. Perhaps you just use debian (or some derivative) and are thus the target for those tarballs, but “portable” they really are not.
As evident by Guix/Nix there is nothing that hard codes the location of libraries - that is if you are willing to abuse LD_PATH and other env variables.
Guix/Nix’s packaging models were specifically designed to get around the massive fucking headache of dynamic linking on Linux.
The way Windows and Linux handle application libraries is not much different. Just because some retarded devs don't properly include the libraries their application depends on doesn't mean it is the fault of Linux. Your precious Windows system does it the same way, but most packaged software for it usually has their libraries down.
Check your Windows folder retard. Look at those DLLs!
When the Windows dynamic linker searches for a .DLL, it first searches the directory the .exe is located in (usually C
![:\](/styles/custom/emotes/svg/chris-confused.svg "Confused :\")
Program Files\<App Name>), before checking the global registry and finally certain hardcoded directories.
When the Linux dynamic linker is searching for a .so, according to the
ld.so man page, is
0. If the library name specified in the binary contains a slash, then it’s interpreted as a path to the library, either absolute or relative. Otherwise, it searches
1. The path specified in the DT_RPATH dynamic section attribute of the binary*,
2. The path(s) specified by the LD_LIBRARY_PATH environment variable
3. The path specified in the DT_RUNPATH dynamic section attribute of the binary,
4. The /etc/ld.so.cache file which contains a cache of already searched for libraries, and finally
5. The /lib and /usr/lib directories.
* Note that if the binary contains a DT_RUNPATH section attribute, the DT_RPATH section attribute is ignored.
TLDR: Linux either searches in hardcoded locations, or it looks for system wide libraries.
Linux also preloads whatever libraries are listed in the LD_PRELOAD environment variable, plus the system-wide C library.
Basically, under Windows, both application-specific and system-wide shared libraries are accommodated by the system on fairly equal footing, while under Linux it is expected that programs will use system-wide libraries and any exceptions must be explicitly specified. It *is* possible to use application specific libraries on Linux, but it’s kinda a pain and you cannot interpose an application-specific library in place of a system-wide one (without going around the linker, at least), you must decide to use one or the other at compile time.
Windows’ model for dynamic linking is only subtly different than Linux’s, but it makes such a big difference for usability it’s insane.
There are many, many things that could have mitigated this problem:
- people could have avoided telling the Tearscape dev to install Arch
- Valve could have required that any game offering Linux binaries, at least start on the last currently supported Ubuntu LTS version
- Valve could have at least provided guidance saying that Linux versions be compiled on the last currently supported Ubuntu LTS or Debian stable version
- Valve could advise developers who don't know what the fuck they're doing with Linux how to either build static images or bundle every single dependency including glibc
If Valve is really serious about Linux, they should come out with some kind of Steam-native containerization system. Maybe they could riff off of AppImages, adding in some kind of libc replacement for maximum compatibility. Throw in a build framework that makes this into a turn-key solution for devs, and it would probably take off.
