4 ms·

besides being slower, splitting them into two would mean they’d need to agree on abi and evolution. Having them ship in the same binary skips over those concern

• Joker_vD 3y ago
  Okay, I've just checked, and apparently the ld and ld.so are two completely different executables: the loader, ld.so, is 236K large and statically linked while ld is 1.7M large and dynamically linked. And now that I think of it, I believe that alternative linkers such as gold, or mold, or lld, don't come with alternative loaders so... they have to manually follow the GNU's ld.so ABI and evolution?
  • LegionMammal978 3y ago
    The terminology is a bit confusing: the ordinary linker used at compile time is gold, or mold, or lld, that outputs an ELF executable. Then, the dynamic linker, or dynamic loader, is provided by the libc and usually called ld-whatever.so. It takes the loaded ELF program as input when you start it, and processes relocations and whatnot before yielding control to the program's entry point. The interface between the compile-time linker and the dynamic linker is mostly defined by the ELF file format, System V ABI, and processor-specific ABI: many of the details can be found in the elf(5) man page. So in principle, there isn't really a bespoke "ld.so ABI". However, in practice, this can break down a bit on the consumer's side; there was a ruckus a while back when glibc started only including the undocumented DT_GNU_HASH and not the documented DT_HASH for its shared libraries, under the premise that only libc should be concerned with interpreting ELF headers. At least from the producer's side, the story is better, since dynamic linkers will generally at least accept the standard headers, and ignore any nonstandard headers they don't understand.