In 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).

▲

pas 5 hours ago | parent [-]

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?

▲

roblabla 4 hours ago | parent [-]

> 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.

That's exactly what they're doing right now - though instead of being "when installing the program", it's "when compiling the program". The problem with hardcoding the path is that it pins the "nix store" (where nix installs all of its programs) to a hardcoded location. If you want to move it, you have to rebuild all your packages - which is suboptimal.

In theory, nix could have a system in place to just patch all binaries when moving the nix store, but that would be incompatible with content-addressed derivation and otherwise break some other nice properties of the nix store.

	▲	setheron an hour ago \| parent [-]
		(author) You did a great job articulating the points!