I don’t have any links at the moment (will try to find some) but here is what is in my head currently (I am probably wrong about some of this):
- Windows, MacOS, and the BSDs all require linking to the system libc, as I understand it
- Linux, as a project, only provides a kernel, and only specifies a syscall interface
- This is a stable interface, a.la. “don’t break userland”
- The GNU project created
glibcwhich provided a “system” libc from userland
Now is the part where this becomes a problem:
- (source needed) The GNU project does not have this same commitment to stability
glibcis not the only possible libc on Linux
Coming back to the point about other systems that require libc, Windows and MacOS are both backed by large corporations that have the power to enforce using that libc, and also have the incentive and organizational capacity to maintain compatibility (although, less so with Apple). So when Vulkan says you should call dlopen("libvulkan.so.1"), this is not seen as an issue, and it solves several problems related to GPU drivers and multiple vendors. It’s only an issue on Linux because it’s the weird duck that doesn’t explicitly ship a system libc.
Add on top of that Linux is more popular as a server (where Windows and MacOS are mostly desktop) and you end up with some decisions being made that make sense for servers but less sense for desktops.
Some other links that are tangetially related:
- GitHub - pfalcon/foreign-dlopen: Small library allowing to use dlopen() from statically-linked applications (where statically-linked executable vs loaded shared library may use completely different libc's)
- https://www.youtube.com/watch?v=pq1XqP4-qOo
Edit: Found some more interesting reads: