alt Hacker NewsIn theory, ld.so could provide a stable interface to its dynamic loading capabilities independently of glibc. Then glibc would not have to be updated in concert with ld.so. There's no inherent reason that glibc should be the library shipping a dynamic linker - we could easily be in a world where libld was developed independently from libc.
On Windows, things are less modular, so it's less of an issue. That said, there's also weird shenanigans when it comes to the CRT (which can be statically linked) vs ntdll (which provides the actual linker implementation), that can make certain niche features of the linker misbehave (delay loading in particular is weird).
Replies
still, eventually there's a need to support on one platform different ld.so/glibc pairs (even if they are API/ABI compatible)
it seems nixos could set up a wrapper that invokes the right ld.so based on the executable. though at this point they could probably edit the ELF binaries and patch the fixed path to ld.so when nix is installing the program.
yeah, it seems strange that this needs kernel support. but more eBFP extension points are usually welcome, so sure, why not?
In practice, ld.so is a piece of glibc. If you want to build ld.so from scratch, you have to clone glibc or get a tarball of glibc, and configure and build glibc.
You could make the argument that the glibc developers should split ld.so into its own subprojects. What for? That would just bring the extra responsibility of making sure that variations in glibc version work with variations in ld.so version for whatever reason.
What would happen in practice is that they would keep their version numbers in lock step, and systems integrators would use the same version. While the upstream glibc has to go through a dance of pretending that someone cares about their independence.