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 <ja...@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 [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 :).

Attachment: signature.asc
Description: This is a digitally signed message part.

Reply via email to