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 unreasonable.
- /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 thought -mike