* Re: Hurd: /lib/ld.so vs. /lib/ld.so.1 (was: Policy: Require new dynamic loader names for entirely new ABIs?)
2014-01-22 15:52 ` Hurd: /lib/ld.so vs. /lib/ld.so.1 (was: Policy: Require new dynamic loader names for entirely new ABIs?) Thomas Schwinge
@ 2014-01-29 6:26 ` Roland McGrath
0 siblings, 0 replies; 2+ messages in thread
From: Roland McGrath @ 2014-01-29 6:26 UTC (permalink / raw)
To: Thomas Schwinge
Cc: bug-hurd, GNU C Library, Joseph S. Myers, Carlos O'Donell, gcc
> 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
^ permalink raw reply [flat|nested] 2+ messages in thread