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