Phone call (was Re: Armhf dynamic linker path)
vapier at gentoo.org
Thu Apr 12 17:49:16 UTC 2012
On Thursday 12 April 2012 03:47:29 Jakub Jelinek wrote:
> On Thu, Apr 12, 2012 at 10:33:08AM +0300, Riku Voipio wrote:
> > On 12 April 2012 09:05, Jakub Jelinek <jakub at redhat.com> wrote:
> > > On Thu, Apr 12, 2012 at 11:22:13AM +1200, Michael Hope wrote:
> > >> All good. My vote is for /lib/ld-arm-linux-gnueabihf.so.3 as it:
> > > The directory should be /libhf/ or /libhfp/ for that for consistency
> > > with all the other architectures. Note e.g. x86_64 dynamic linker
> > > is /lib64/ld-linux-x86-64.so.2, not /lib/ld-linux-x86-64.so.2.
> > For some value of consistency. x86_64, mips64, powerpc64 and sparc64
> > install to /lib64. But on ia64 it is /lib/ld-linux-ia64.so.2 and on
> ia64 installs in /lib, because it isn't a multilibbed architecture.
because distros choose not to support it. in first gen chips, there was
hardware support for running x86. so if we were to be strict, there should
have been /libia64/ (or whatever) while the current x86 32bit code would stay
in /lib/. but no distro was interested in supporting that (probably due to
the 32bit x86 layers being balls-ass slow), so it never happened.
> > s390x it is /lib/ld64.so.1 .
> Ok, I forgot about this, I've tried to convince s390x folks to move it
> to /lib64/ld64.so.1 many years ago, but that just didn't happen, so
> /lib/ld64.so.1 is just a symlink to /lib64/ld64.so.1.
> Upstream glibc binaries use /lib64/ld64.so.1 as their dynamic linker,
> while all other packages use /lib/ld64.so.1 as that is hardcoded in gcc.
i always thought this was weird. glad to know i'm not the only one :).
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 836 bytes
Desc: This is a digitally signed message part.
More information about the linaro-toolchain