> For x86 Hurd, GCC has been specifying »-dynamic-linker /lib/ld.so« in > LINK_SPEC since forever (1995, or earlier), and Debian glibc has had the > following since forever (2002, or earlier): > > ifeq ($(DEB_HOST_GNU_SYSTEM),gnu) > # Why doesn't the glibc makefile install this? > ln -sf ld.so.1 $(tmpdir)/$@/lib/ld.so > endif > > Roland, do you have any recollection of this? Assuming that /lib/ld.so.1 > is the "official" name, I suppose GCC should be changed, and then Debian > could drop the symbolic link after a transition period (full archive > rebuilt, etc.).
The original rationale was that these are two different strings indicating two different kinds of compatibility, and that there would be symlinks from both of these names to the same implementation at any given moment. That thinking goes like this: /lib/ld.so is the PT_INTERP string. That identifies the ELF dynamic linker layer of the ABI. That doesn't need to change as long as programs' use of ELF headers, symbol tables, and so forth does not need new or different behavior. ld.so.1 is the SONAME string. That identifies the DSO that happens also to be the dynamic linker, and its particular DSO ABI just as the SONAME of any other DSO identifies that DSO's ABI. That needs to change any time the set of symbols exported by the dynamic linker changes incompatibly. (All this rationale pre-dates the symbol versioning features by a few years.) Those notions remain sound as to what each string means. But practical reality and years of experience lead in different directions. It has become very clear that by far the easiest way to retain compatibility for a variety of binary vintages and flavors sharing a filesystem is to have their loading paths diverge as early as possible. PT_INTERP is the earliest step in the process that is really under userland control, so that's the spot. It's trivial to make multiple names resolve to the same actual thing (with symlinks) when one thing can serve multiple flavors/vintages but it's very difficult to go in the other direction. That says that if the canonical PT_INTERP string for Hurd is going to change, it might as well change in the direction of being much more specific. e.g. /lib/ld-gnu-i386.so.1 or something like that. Thanks, Roland