Armhf dynamic linker path
vapier at gentoo.org
Wed Apr 11 03:01:47 UTC 2012
On Tuesday 10 April 2012 06:42:04 Steve McIntyre wrote:
> We understand that not everybody may want or see the need for this for
> themselves. We *really* get that. But we want it to be possible for
> *us* to do it, and an ultra-important part of that is to have unique
> loader paths wherever possible. Hence the discussion over the location
> for the arm hard-float linker. We've built our systems using the
> multi-arch path as that worked well for us and doesn't hurt anybody
> else. There are problems with some of the other options here:
> * /lib/ld-linux.so.3
no one suggested this
> * /libhf/ld-linux.so.3
> - it could readily clash with a future hard-float platform; look
> how /lib64/* could clash with amd64/ARMv8/ppc64/sparc64 all
> populating it in the near future
> * /lib/ld-linux-hf.so.3
> - similar problem
so you're saying Debian would never accept any ldso path for any arch on the
future possibility that it could collide with another target ? that's a bit
> * /lib/ld-linux-$triplet.so.3
> - could work fine, so long as we can agree on triplets
kind of a waste of space, and the definition of "triplet" is vague, and in your
example here, the word "linux" uselessly appears twice.
once the duplicate "linux" word is fixed, i wouldn't fight this.
> In Debian and Ubuntu, we have implemented the last one of these three
> and it's working fine for us. We had understood that in previous
> cross-distro discussions (e.g. at Plumbers last year) there was
> agreement on this, but we're now seeing dissent. Ubuntu are expecting
> (by the end of this month) to be the first distro to ship a stable
> release using the hard-float ABI on ARM, so it's unfortunate that this
> argument is happening now.
one of the downsides of traveling down a path and upstreaming as an after
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 836 bytes
Desc: This is a digitally signed message part.
More information about the cross-distro