Re: Is this part of newer filesystem hierarchy?

[Keith Owens <kaos@ocs.com.au>]

On Sat, 23 Jun 2001 19:09:12 -0600, 
"D. Stimits" <stimits@idcomm.com> wrote:
>There is a directory on RH 7.1 x86, /lib/i686/. When checking with ldd
>to various applications, as to which libc they link to, it turns out
>that the /lib/libc.so.6 is not used. They all seem to point at
>/lib/i686/libc.so.6 (this is the version with debugging symbols) by
>default. The odd thing is that there are NO LD_ style path variables set
>on this system, there is NO /etc/ld.so.preload, and /etc/ld.so.conf does
>not contain any reference to /lib/i686/. So there is a question of just
>how it is possible for ld to use that directory and ignore /lib/ for
>libc.so.6.

15 minutes with a few commands, man pages and the source of glibc will
show you this ...

# /sbin/ldconfig -p | fgrep -w libc
libc.so.6 (libc6, hwcap: 0x8000000000000, OS ABI: Linux 2.4.1) => /lib/i686/libc.so.6
libc.so.6 (libc6, OS ABI: Linux 2.2.5) => /lib/libc.so.6

The data is coming from /etc/ld.so.cache which is build by ldconfig.
A quick scan of the source for ldconfig.c in glibc 2.2.2 shows that it
starts with standard paths /lib and /usr/lib then searches those
directories and all their subdirectories looking for libraries.  That
explains why it finds /lib/i686 without being explicitly specified.

Note the hwcap entry in /lib/i686/libc.so.6.  The dynamic linker no
longer takes the first entry it finds for a library, instead it looks
for the first entry that matches the current hardware.  This is
required for machines like ia64 which can also run i386 binaries and
for sparc which can run 32 or 64 bit apps.