Is this part of newer filesystem hierarchy?

Is this part of newer filesystem hierarchy?

[D. Stimits]

I found on my newer Redhat 7.1 distribution that glibc is being placed
differently than just /lib/. Here is the structure I found:

/lib/ has:
libc-2.2.2.so (hard link)
libc.so.6     (sym link to above)

A new directory appears, /lib/i686/ (uname -m is i686):
libc-2.2.2.so (a full hard link copy of /lib/ version)
libc.so.6     (sym link to hard link in this directory)

The file size of /lib/libc-2.2.2.so is around 1.2 MB, while the size of
/lib/i686/libc-2.2.2.so is over 5 MB. The 5 MB version has symbols,
while the 1.2 MB version is stripped.

Here is the peculiar part that I need to find out about. My
/lib/ld.so.conf does not contain the i686 directory in its path. Nor do
any local LD environment variables. Even so, "ldconfig -p" lists *only*
the libc.so.6 sym link, not the libc-2.2.2.so, and the one listed is for
the i686 subdirectory, not the /lib/ directory. How is it possible that
the i686 directory is being checked if it is not listed in ld.so.conf
and not part of any LD path variable? I am using a non-Redhat kernel
(patched 2.4.6-pre1), so I know it isn't a Redhat-ism related to the
kernel itself. My ld version:
~# ld --version
GNU ld 2.10.91
Copyright 2001 Free Software Foundation, Inc.
This program is free software; you may redistribute it under the terms
of
the GNU General Public License.  This program has absolutely no
warranty.
  Supported emulations:
   elf_i386
   i386linux
   elf_i386_glibc21

Possibly Redhat altered ld? According to the man page, this directory
should not be found since it is not part of ld.so.conf, and also the
/lib/ version *should* be found (but isn't). What has changed, is it a
standard for filesystem hierarchy, or is it something distribution
specific? (I need to pass the answer along to someone working on
customized boot software that is currently being confused by this
distinction; there is a need to find a proper means to detect libc and
linker information)

D. Stimits, stimits@idcomm.com

Re: Is this part of newer filesystem hierarchy?

[Luigi Genoni]

I do not know if this is a new filesystem hierarchy, it should not be,
at less untill lsb finishes all discussion (anyway it is similar to lsb
standard). Your mail is a little confusing for me. Let's see if i can
clarify my ideas.

On Thu, 21 Jun 2001, D. Stimits wrote:

> I found on my newer Redhat 7.1 distribution that glibc is being placed
> differently than just /lib/. Here is the structure I found:
>
> /lib/ has:
> libc-2.2.2.so (hard link)
> libc.so.6     (sym link to above)
>
> A new directory appears, /lib/i686/ (uname -m is i686):
> libc-2.2.2.so (a full hard link copy of /lib/ version)
> libc.so.6     (sym link to hard link in this directory)
>
> The file size of /lib/libc-2.2.2.so is around 1.2 MB, while the size of
> /lib/i686/libc-2.2.2.so is over 5 MB. The 5 MB version has symbols,
> while the 1.2 MB version is stripped.
>
> Here is the peculiar part that I need to find out about. My
> /lib/ld.so.conf does not contain the i686 directory in its path. Nor do
> any local LD environment variables. Even so, "ldconfig -p" lists *only*
> the libc.so.6 sym link, not the libc-2.2.2.so, and the one listed is for
> the i686 subdirectory, not the /lib/ directory. How is it possible that
> the i686 directory is being checked if it is not listed in ld.so.conf
> and not part of any LD path variable? I am using a non-Redhat kernel
> (patched 2.4.6-pre1), so I know it isn't a Redhat-ism related to the
> kernel itself. My ld version:
excuse, but if you do something like,
ldd /bin/ls

what do you get, which libc is loaded?

have you got a file like /etc/ld.so.preload??
basically you can use the stripped glibc (faster), but then,
if you have troubles and you need to debug, just set the preload file,
or use LD_PRELOAD variable to use
the non stripped library. In princip it is not a stupid idea,
not that i like it, but it is not stupid.

> ~# ld --version
> GNU ld 2.10.91
> Copyright 2001 Free Software Foundation, Inc.
> This program is free software; you may redistribute it under the terms
> of
> the GNU General Public License.  This program has absolutely no
> warranty.
>   Supported emulations:
>    elf_i386
>    i386linux
>    elf_i386_glibc21
>
> Possibly Redhat altered ld? According to the man page, this directory
> should not be found since it is not part of ld.so.conf, and also the
> /lib/ version *should* be found (but isn't). What has changed, is it a
> standard for filesystem hierarchy, or is it something distribution
> specific? (I need to pass the answer along to someone working on
> customized boot software that is currently being confused by this
> distinction; there is a need to find a proper means to detect libc and
> linker information)
ld links dynamic libraries if the final extension is .so (usually a link),
and uses the soname (usually a link too, created by ldconfig), for
the binaries it generates, otherway it will use .a library archives.
/usr/lib/libc.so (the file used by ld to link glibc), is a script. There
are good reason for that, with libc5 it was a link to /lib/libc.so.5
(soname).
ld loocks for .so files as is configured
inside of the files in /usr/<arch/host name>/lib/ldscripts

please note that usually for klibraries inside of /lib, the .so link is in
/usr/lib, or at less it should.

syntax is like:
SEARCH_DIR(/lib); SEARCH_DIR(/usr/lib); SEARCH_DIR(/usr/local/lib); \
SEARCH_DIR(/usr/i386-slackware-linux/lib);

(that is why you need to pass -L/usr/X11R6/lib to link X11 apps
at runtime) anyway to load shared libraries is managed by
/lib/ld-2.XXX.so, using
the db created by ldconfig that uses /etc/ld.so.conf
as its configuration file.

Luigi Genoni

Re: Is this part of newer filesystem hierarchy?

[D. Stimits]

Luigi Genoni wrote:
> 
> I do not know if this is a new filesystem hierarchy, it should not be,
> at less untill lsb finishes all discussion (anyway it is similar to lsb
> standard). Your mail is a little confusing for me. Let's see if i can
> clarify my ideas.
> 
> On Thu, 21 Jun 2001, D. Stimits wrote:
> 
> > I found on my newer Redhat 7.1 distribution that glibc is being placed
> > differently than just /lib/. Here is the structure I found:
> >
> > /lib/ has:
> > libc-2.2.2.so (hard link)
> > libc.so.6     (sym link to above)
> >
> > A new directory appears, /lib/i686/ (uname -m is i686):
> > libc-2.2.2.so (a full hard link copy of /lib/ version)
> > libc.so.6     (sym link to hard link in this directory)
> >
> > The file size of /lib/libc-2.2.2.so is around 1.2 MB, while the size of
> > /lib/i686/libc-2.2.2.so is over 5 MB. The 5 MB version has symbols,
> > while the 1.2 MB version is stripped.
> >
> > Here is the peculiar part that I need to find out about. My
> > /lib/ld.so.conf does not contain the i686 directory in its path. Nor do
> > any local LD environment variables. Even so, "ldconfig -p" lists *only*
> > the libc.so.6 sym link, not the libc-2.2.2.so, and the one listed is for
> > the i686 subdirectory, not the /lib/ directory. How is it possible that
> > the i686 directory is being checked if it is not listed in ld.so.conf
> > and not part of any LD path variable? I am using a non-Redhat kernel
> > (patched 2.4.6-pre1), so I know it isn't a Redhat-ism related to the
> > kernel itself. My ld version:
> excuse, but if you do something like,
> ldd /bin/ls
> 
> what do you get, which libc is loaded?

:~# ldd /bin/ls
  libtermcap.so.2 => /lib/libtermcap.so.2 (0x4002a000)
  libc.so.6 => /lib/i686/libc.so.6 (0x4002e000)
  /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)

The i686 subdirectory version is visible to the linker. I don't know
how.

> 
> have you got a file like /etc/ld.so.preload??

No. Nor are any preload or LD environment variables set. Something
Redhat has done is making the i686 subdirectory visible. Maybe ld
searches recursively?

> basically you can use the stripped glibc (faster), but then,
> if you have troubles and you need to debug, just set the preload file,
> or use LD_PRELOAD variable to use
> the non stripped library. In princip it is not a stupid idea,
> not that i like it, but it is not stupid.

Without any preload, it appears the linker is by default choosing the
debug version in the i686 subdirectory. Redhat must have mucked with it,
otherwise I don't see how it could be searching the i686 subdirectory
without any configuration customization (no preload, no LD environment
variables). But this is what I want to verify...where the "mucking" has
occurred, it is important to find out for some software that is used to
create custom and/or rescue disks. (alternately, to find out if there is
a predictable scheme, such as knowning ld is searching recursively, or
searches for /lib/{uname -m})

> 
> > ~# ld --version
> > GNU ld 2.10.91
> > Copyright 2001 Free Software Foundation, Inc.
> > This program is free software; you may redistribute it under the terms
> > of
> > the GNU General Public License.  This program has absolutely no
> > warranty.
> >   Supported emulations:
> >    elf_i386
> >    i386linux
> >    elf_i386_glibc21
> >
> > Possibly Redhat altered ld? According to the man page, this directory
> > should not be found since it is not part of ld.so.conf, and also the
> > /lib/ version *should* be found (but isn't). What has changed, is it a
> > standard for filesystem hierarchy, or is it something distribution
> > specific? (I need to pass the answer along to someone working on
> > customized boot software that is currently being confused by this
> > distinction; there is a need to find a proper means to detect libc and
> > linker information)
> ld links dynamic libraries if the final extension is .so (usually a link),
> and uses the soname (usually a link too, created by ldconfig), for
> the binaries it generates, otherway it will use .a library archives.
> /usr/lib/libc.so (the file used by ld to link glibc), is a script. There
> are good reason for that, with libc5 it was a link to /lib/libc.so.5
> (soname).
> ld loocks for .so files as is configured
> inside of the files in /usr/<arch/host name>/lib/ldscripts

Interesting that there is a /usr/i386-glibc21-linux/ directory, but
glibc 2.2 is used. In /usr/i386-glibc21-linux/lib/ is file
libc-2.1.3.so, which matches this particular naming, but ldconfig -p
does not indicate this directory is searched. There is no ldscripts,
either as a file name or a directory name. The visible directory tree
there is:
/usr/i386-glibc21-linux/ as base, then these:
-- lib
    `-- gcc-lib
        `-- i386-redhat-linux
            `-- 2.96
                `-- include
->../../../../../lib/gcc-lib/i386-glibc21-linux/egcs-2.91.66/include



> 
> please note that usually for klibraries inside of /lib, the .so link is in
> /usr/lib, or at less it should.
> 
> syntax is like:
> SEARCH_DIR(/lib); SEARCH_DIR(/usr/lib); SEARCH_DIR(/usr/local/lib); \
> SEARCH_DIR(/usr/i386-slackware-linux/lib);
> 
> (that is why you need to pass -L/usr/X11R6/lib to link X11 apps
> at runtime) anyway to load shared libraries is managed by
> /lib/ld-2.XXX.so, using
> the db created by ldconfig that uses /etc/ld.so.conf
> as its configuration file.

There must be something more, since the i686 subdirectory is being
searched without ld.so.conf and without environment variables pointing
at it (e.g., recursive search from any named directory).

D. Stimits, stimits@idcomm.com

> 
> Luigi Genoni
> 
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/

Re: Is this part of newer filesystem hierarchy?

[Luigi Genoni]

Again i am confused.

/usr/bin/ld is linker at compilation time, at it works how i told in
second part
of my mail, (just try to compile it, it comes with binutils,
ftp.kernel.org/pub/linux/devel/binutils).

/lib/d-2.2.X.so  is what you are talking about.
So should i think os an hack to ld-2.2.3.so ??

to see how it works loock at /usr/bin/ldd, it's an interesting script.

I can understand why old glibc 2.1 is not isered in the directories
where ldconfig has to loock to create its db for loader, but there should
be a corrispective /usr/i386-(redhat/glibc2.2???)-linux/ (with its
subdirectories)
for glibc 2.2, since it is necessary at compilation
time.
This do not change the problem which is related to /lib/ld-2.2.X.so.
doing a strings /lib/ld-2.XXX
you will find also

info[19]->d_un.d_val == sizeof (Elf32_Rel)
info[20]->d_un.d_val == 17
/lib/
/usr/lib/
{ORIGIN}
{PLATFORM}
expand_dynamic_string_token
dl-load.c

this is the interesting section of the output. This way you can check for
an hack to the loader, but I think to something else instead of an hack.

I do not have a red hat here around, since i do prefer another style for
my linux systems, so i cannot check by person.

Luigi Genoni

On Fri, 22 Jun 2001, D. Stimits wrote:

> Luigi Genoni wrote:
> >
> > I do not know if this is a new filesystem hierarchy, it should not be,
> > at less untill lsb finishes all discussion (anyway it is similar to lsb
> > standard). Your mail is a little confusing for me. Let's see if i can
> > clarify my ideas.
> >
> > On Thu, 21 Jun 2001, D. Stimits wrote:
> >
> > > I found on my newer Redhat 7.1 distribution that glibc is being placed
> > > differently than just /lib/. Here is the structure I found:
> > >
> > > /lib/ has:
> > > libc-2.2.2.so (hard link)
> > > libc.so.6     (sym link to above)
> > >
> > > A new directory appears, /lib/i686/ (uname -m is i686):
> > > libc-2.2.2.so (a full hard link copy of /lib/ version)
> > > libc.so.6     (sym link to hard link in this directory)
> > >
> > > The file size of /lib/libc-2.2.2.so is around 1.2 MB, while the size of
> > > /lib/i686/libc-2.2.2.so is over 5 MB. The 5 MB version has symbols,
> > > while the 1.2 MB version is stripped.
> > >
> > > Here is the peculiar part that I need to find out about. My
> > > /lib/ld.so.conf does not contain the i686 directory in its path. Nor do
> > > any local LD environment variables. Even so, "ldconfig -p" lists *only*
> > > the libc.so.6 sym link, not the libc-2.2.2.so, and the one listed is for
> > > the i686 subdirectory, not the /lib/ directory. How is it possible that
> > > the i686 directory is being checked if it is not listed in ld.so.conf
> > > and not part of any LD path variable? I am using a non-Redhat kernel
> > > (patched 2.4.6-pre1), so I know it isn't a Redhat-ism related to the
> > > kernel itself. My ld version:
> > excuse, but if you do something like,
> > ldd /bin/ls
> >
> > what do you get, which libc is loaded?
>
> :~# ldd /bin/ls
>   libtermcap.so.2 => /lib/libtermcap.so.2 (0x4002a000)
>   libc.so.6 => /lib/i686/libc.so.6 (0x4002e000)
>   /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)
>
> The i686 subdirectory version is visible to the linker. I don't know
> how.
>
> >
> > have you got a file like /etc/ld.so.preload??
>
> No. Nor are any preload or LD environment variables set. Something
> Redhat has done is making the i686 subdirectory visible. Maybe ld
> searches recursively?
>
> > basically you can use the stripped glibc (faster), but then,
> > if you have troubles and you need to debug, just set the preload file,
> > or use LD_PRELOAD variable to use
> > the non stripped library. In princip it is not a stupid idea,
> > not that i like it, but it is not stupid.
>
> Without any preload, it appears the linker is by default choosing the
> debug version in the i686 subdirectory. Redhat must have mucked with it,
> otherwise I don't see how it could be searching the i686 subdirectory
> without any configuration customization (no preload, no LD environment
> variables). But this is what I want to verify...where the "mucking" has
> occurred, it is important to find out for some software that is used to
> create custom and/or rescue disks. (alternately, to find out if there is
> a predictable scheme, such as knowning ld is searching recursively, or
> searches for /lib/{uname -m})
>
> >
> > > ~# ld --version
> > > GNU ld 2.10.91
> > > Copyright 2001 Free Software Foundation, Inc.
> > > This program is free software; you may redistribute it under the terms
> > > of
> > > the GNU General Public License.  This program has absolutely no
> > > warranty.
> > >   Supported emulations:
> > >    elf_i386
> > >    i386linux
> > >    elf_i386_glibc21
> > >
> > > Possibly Redhat altered ld? According to the man page, this directory
> > > should not be found since it is not part of ld.so.conf, and also the
> > > /lib/ version *should* be found (but isn't). What has changed, is it a
> > > standard for filesystem hierarchy, or is it something distribution
> > > specific? (I need to pass the answer along to someone working on
> > > customized boot software that is currently being confused by this
> > > distinction; there is a need to find a proper means to detect libc and
> > > linker information)
> > ld links dynamic libraries if the final extension is .so (usually a link),
> > and uses the soname (usually a link too, created by ldconfig), for
> > the binaries it generates, otherway it will use .a library archives.
> > /usr/lib/libc.so (the file used by ld to link glibc), is a script. There
> > are good reason for that, with libc5 it was a link to /lib/libc.so.5
> > (soname).
> > ld loocks for .so files as is configured
> > inside of the files in /usr/<arch/host name>/lib/ldscripts
>
> Interesting that there is a /usr/i386-glibc21-linux/ directory, but
> glibc 2.2 is used. In /usr/i386-glibc21-linux/lib/ is file
> libc-2.1.3.so, which matches this particular naming, but ldconfig -p
> does not indicate this directory is searched. There is no ldscripts,
> either as a file name or a directory name. The visible directory tree
> there is:
> /usr/i386-glibc21-linux/ as base, then these:
> -- lib
>     `-- gcc-lib
>         `-- i386-redhat-linux
>             `-- 2.96
>                 `-- include
> ->../../../../../lib/gcc-lib/i386-glibc21-linux/egcs-2.91.66/include
>
>
>
> >
> > please note that usually for klibraries inside of /lib, the .so link is in
> > /usr/lib, or at less it should.
> >
> > syntax is like:
> > SEARCH_DIR(/lib); SEARCH_DIR(/usr/lib); SEARCH_DIR(/usr/local/lib); \
> > SEARCH_DIR(/usr/i386-slackware-linux/lib);
> >
> > (that is why you need to pass -L/usr/X11R6/lib to link X11 apps
> > at runtime) anyway to load shared libraries is managed by
> > /lib/ld-2.XXX.so, using
> > the db created by ldconfig that uses /etc/ld.so.conf
> > as its configuration file.
>
> There must be something more, since the i686 subdirectory is being
> searched without ld.so.conf and without environment variables pointing
> at it (e.g., recursive search from any named directory).
>
> D. Stimits, stimits@idcomm.com
>
> >
> > Luigi Genoni
> >
> > -
> > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> > the body of a message to majordomo@vger.kernel.org
> > More majordomo info at  http://vger.kernel.org/majordomo-info.html
> > Please read the FAQ at  http://www.tux.org/lkml/
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
>

Re: Is this part of newer filesystem hierarchy?

[D. Stimits]

Luigi Genoni wrote:
> 
> Again i am confused.
> 
> /usr/bin/ld is linker at compilation time, at it works how i told in
> second part
> of my mail, (just try to compile it, it comes with binutils,
> ftp.kernel.org/pub/linux/devel/binutils).
> 
> /lib/d-2.2.X.so  is what you are talking about.
> So should i think os an hack to ld-2.2.3.so ??

The RH 7.1 comes with:
:~# ld --version
GNU ld 2.10.91
Copyright 2001 Free Software Foundation, Inc.
This program is free software; you may redistribute it under the terms
of
the GNU General Public License.  This program has absolutely no
warranty.
  Supported emulations:
   elf_i386
   i386linux
   elf_i386_glibc21

The glibc rpm is version 2.2.2-10.

> 
> to see how it works loock at /usr/bin/ldd, it's an interesting script.
> 
> I can understand why old glibc 2.1 is not isered in the directories
> where ldconfig has to loock to create its db for loader, but there should
> be a corrispective /usr/i386-(redhat/glibc2.2???)-linux/ (with its
> subdirectories)
> for glibc 2.2, since it is necessary at compilation
> time.

There is *no* /usr/i386-xxx except for:
/usr/i386-glibc21-linux/

No glibc22 version exists.

> This do not change the problem which is related to /lib/ld-2.2.X.so.
> doing a strings /lib/ld-2.XXX
> you will find also
> 
> info[19]->d_un.d_val == sizeof (Elf32_Rel)
> info[20]->d_un.d_val == 17
> /lib/
> /usr/lib/
> {ORIGIN}
> {PLATFORM}
> expand_dynamic_string_token
> dl-load.c

"i686" is visible on a line by itself, but so are i386, i486, and i586.
The full path of /lib/i686/ is not mentioned anywhere. So it looks like
strings of /lib/ld-2* does not offer any hints as to how the i686
subdirectory is being chosen without it being specified anywhere else. I
think this will end up just being one of those mysteries, and the boot
software coder will have to find some non-trivial workaround. It sounds
like the /lib/i686/ path was hardcoded in the linker when it was
compiled, which means there are no simple config file checks.

D. Stimits, stimits@idcomm.com

> 
> this is the interesting section of the output. This way you can check for
> an hack to the loader, but I think to something else instead of an hack.
> 
> I do not have a red hat here around, since i do prefer another style for
> my linux systems, so i cannot check by person.
> 
> Luigi Genoni
> 
> On Fri, 22 Jun 2001, D. Stimits wrote:
> 
> > Luigi Genoni wrote:
> > >
> > > I do not know if this is a new filesystem hierarchy, it should not be,
> > > at less untill lsb finishes all discussion (anyway it is similar to lsb
> > > standard). Your mail is a little confusing for me. Let's see if i can
> > > clarify my ideas.
> > >
> > > On Thu, 21 Jun 2001, D. Stimits wrote:
> > >
> > > > I found on my newer Redhat 7.1 distribution that glibc is being placed
> > > > differently than just /lib/. Here is the structure I found:
> > > >
> > > > /lib/ has:
> > > > libc-2.2.2.so (hard link)
> > > > libc.so.6     (sym link to above)
> > > >
> > > > A new directory appears, /lib/i686/ (uname -m is i686):
> > > > libc-2.2.2.so (a full hard link copy of /lib/ version)
> > > > libc.so.6     (sym link to hard link in this directory)
> > > >
> > > > The file size of /lib/libc-2.2.2.so is around 1.2 MB, while the size of
> > > > /lib/i686/libc-2.2.2.so is over 5 MB. The 5 MB version has symbols,
> > > > while the 1.2 MB version is stripped.
> > > >
> > > > Here is the peculiar part that I need to find out about. My
> > > > /lib/ld.so.conf does not contain the i686 directory in its path. Nor do
> > > > any local LD environment variables. Even so, "ldconfig -p" lists *only*
> > > > the libc.so.6 sym link, not the libc-2.2.2.so, and the one listed is for
> > > > the i686 subdirectory, not the /lib/ directory. How is it possible that
> > > > the i686 directory is being checked if it is not listed in ld.so.conf
> > > > and not part of any LD path variable? I am using a non-Redhat kernel
> > > > (patched 2.4.6-pre1), so I know it isn't a Redhat-ism related to the
> > > > kernel itself. My ld version:
> > > excuse, but if you do something like,
> > > ldd /bin/ls
> > >
> > > what do you get, which libc is loaded?
> >
> > :~# ldd /bin/ls
> >   libtermcap.so.2 => /lib/libtermcap.so.2 (0x4002a000)
> >   libc.so.6 => /lib/i686/libc.so.6 (0x4002e000)
> >   /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)
> >
> > The i686 subdirectory version is visible to the linker. I don't know
> > how.
> >
> > >
> > > have you got a file like /etc/ld.so.preload??
> >
> > No. Nor are any preload or LD environment variables set. Something
> > Redhat has done is making the i686 subdirectory visible. Maybe ld
> > searches recursively?
> >
> > > basically you can use the stripped glibc (faster), but then,
> > > if you have troubles and you need to debug, just set the preload file,
> > > or use LD_PRELOAD variable to use
> > > the non stripped library. In princip it is not a stupid idea,
> > > not that i like it, but it is not stupid.
> >
> > Without any preload, it appears the linker is by default choosing the
> > debug version in the i686 subdirectory. Redhat must have mucked with it,
> > otherwise I don't see how it could be searching the i686 subdirectory
> > without any configuration customization (no preload, no LD environment
> > variables). But this is what I want to verify...where the "mucking" has
> > occurred, it is important to find out for some software that is used to
> > create custom and/or rescue disks. (alternately, to find out if there is
> > a predictable scheme, such as knowning ld is searching recursively, or
> > searches for /lib/{uname -m})
> >
> > >
> > > > ~# ld --version
> > > > GNU ld 2.10.91
> > > > Copyright 2001 Free Software Foundation, Inc.
> > > > This program is free software; you may redistribute it under the terms
> > > > of
> > > > the GNU General Public License.  This program has absolutely no
> > > > warranty.
> > > >   Supported emulations:
> > > >    elf_i386
> > > >    i386linux
> > > >    elf_i386_glibc21
> > > >
> > > > Possibly Redhat altered ld? According to the man page, this directory
> > > > should not be found since it is not part of ld.so.conf, and also the
> > > > /lib/ version *should* be found (but isn't). What has changed, is it a
> > > > standard for filesystem hierarchy, or is it something distribution
> > > > specific? (I need to pass the answer along to someone working on
> > > > customized boot software that is currently being confused by this
> > > > distinction; there is a need to find a proper means to detect libc and
> > > > linker information)
> > > ld links dynamic libraries if the final extension is .so (usually a link),
> > > and uses the soname (usually a link too, created by ldconfig), for
> > > the binaries it generates, otherway it will use .a library archives.
> > > /usr/lib/libc.so (the file used by ld to link glibc), is a script. There
> > > are good reason for that, with libc5 it was a link to /lib/libc.so.5
> > > (soname).
> > > ld loocks for .so files as is configured
> > > inside of the files in /usr/<arch/host name>/lib/ldscripts
> >
> > Interesting that there is a /usr/i386-glibc21-linux/ directory, but
> > glibc 2.2 is used. In /usr/i386-glibc21-linux/lib/ is file
> > libc-2.1.3.so, which matches this particular naming, but ldconfig -p
> > does not indicate this directory is searched. There is no ldscripts,
> > either as a file name or a directory name. The visible directory tree
> > there is:
> > /usr/i386-glibc21-linux/ as base, then these:
> > -- lib
> >     `-- gcc-lib
> >         `-- i386-redhat-linux
> >             `-- 2.96
> >                 `-- include
> > ->../../../../../lib/gcc-lib/i386-glibc21-linux/egcs-2.91.66/include
> >
> >
> >
> > >
> > > please note that usually for klibraries inside of /lib, the .so link is in
> > > /usr/lib, or at less it should.
> > >
> > > syntax is like:
> > > SEARCH_DIR(/lib); SEARCH_DIR(/usr/lib); SEARCH_DIR(/usr/local/lib); \
> > > SEARCH_DIR(/usr/i386-slackware-linux/lib);
> > >
> > > (that is why you need to pass -L/usr/X11R6/lib to link X11 apps
> > > at runtime) anyway to load shared libraries is managed by
> > > /lib/ld-2.XXX.so, using
> > > the db created by ldconfig that uses /etc/ld.so.conf
> > > as its configuration file.
> >
> > There must be something more, since the i686 subdirectory is being
> > searched without ld.so.conf and without environment variables pointing
> > at it (e.g., recursive search from any named directory).
> >
> > D. Stimits, stimits@idcomm.com
> >
> > >
> > > Luigi Genoni
> > >
> > > -
> > > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> > > the body of a message to majordomo@vger.kernel.org
> > > More majordomo info at  http://vger.kernel.org/majordomo-info.html
> > > Please read the FAQ at  http://www.tux.org/lkml/
> > -
> > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> > the body of a message to majordomo@vger.kernel.org
> > More majordomo info at  http://vger.kernel.org/majordomo-info.html
> > Please read the FAQ at  http://www.tux.org/lkml/
> >
> 
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/

Re: Is this part of newer filesystem hierarchy?

[Luigi Genoni]

On Fri, 22 Jun 2001, D. Stimits wrote:

> Luigi Genoni wrote:
> >
> > Again i am confused.
> >
> > /usr/bin/ld is linker at compilation time, at it works how i told in
> > second part
> > of my mail, (just try to compile it, it comes with binutils,
> > ftp.kernel.org/pub/linux/devel/binutils).
> >
> > /lib/d-2.2.X.so  is what you are talking about.
> > So should i think os an hack to ld-2.2.3.so ??
>
> The RH 7.1 comes with:
> :~# ld --version
> GNU ld 2.10.91
> Copyright 2001 Free Software Foundation, Inc.
> This program is free software; you may redistribute it under the terms
> of
> the GNU General Public License.  This program has absolutely no
> warranty.
>   Supported emulations:
>    elf_i386
>    i386linux
>    elf_i386_glibc21
Ok, this is the linker for compilation time, it
is not related to the loader for shared libraries. You can even remove
/usr/bin/ld, and the system will run anyway binaries, but you will not be
able to link compiled objects.
try a find for the directory ldscripts or for those files,

elf_i386.x    elf_i386.xs   i386coff.xn  i386linux.xbn
elf_i386.xbn  elf_i386.xu   i386coff.xr  i386linux.xn
elf_i386.xn   i386coff.x    i386coff.xu  i386linux.xr
elf_i386.xr   i386coff.xbn  i386linux.x  i386linux.xu

you could not find the *coff* ones....
those are the configuration file (unproper definition, i ask
excuse for my english), for /usr/bin/ld you are running
doing ld --version.
>
> The glibc rpm is version 2.2.2-10.
>
> >
> > to see how it works loock at /usr/bin/ldd, it's an interesting script.
> >
> > I can understand why old glibc 2.1 is not isered in the directories
> > where ldconfig has to loock to create its db for loader, but there should
> > be a corrispective /usr/i386-(redhat/glibc2.2???)-linux/ (with its
> > subdirectories)
> > for glibc 2.2, since it is necessary at compilation
> > time.
>
> There is *no* /usr/i386-xxx except for:
> /usr/i386-glibc21-linux/
name could be different, just could you e-mail the output for
the command tree inside of /usr?
>
> No glibc22 version exists.
>
> > This do not change the problem which is related to /lib/ld-2.2.X.so.
> > doing a strings /lib/ld-2.XXX
> > you will find also
> >
> > info[19]->d_un.d_val == sizeof (Elf32_Rel)
> > info[20]->d_un.d_val == 17
> > /lib/
> > /usr/lib/
> > {ORIGIN}
> > {PLATFORM}
> > expand_dynamic_string_token
> > dl-load.c
>
> "i686" is visible on a line by itself, but so are i386, i486, and i586.
this is another thing...
> The full path of /lib/i686/ is not mentioned anywhere. So it looks like
> strings of /lib/ld-2* does not offer any hints as to how the i686
> subdirectory is being chosen without it being specified anywhere else. I
> think this will end up just being one of those mysteries, and the boot
> software coder will have to find some non-trivial workaround. It sounds
> like the /lib/i686/ path was hardcoded in the linker when it was
> compiled, which means there are no simple config file checks.
and then they compiled ALL other binaries from scratch with new linker,
passing /lib/i686/libc.so.6 explivitally, or changing the script
/usr/lib/libc.so?

boh! I do not know, and I am not thinking I am going to install a Red Hat
right now (simply it is not suitable for my needs, it is a great
distribution, of course, but it is not what my users need).

want my suggestion?
upgrade to glibc 2.2.3 and to binutils 2.11.90.0.19 building
them from sources against 2.4.X kernel includes. And you wil see if it
works how you would expect.

Luigi

Re: Is this part of newer filesystem hierarchy?

[D. Stimits]

Luigi Genoni wrote:
> 
> On Fri, 22 Jun 2001, D. Stimits wrote:
> 
> > Luigi Genoni wrote:
> > >
> > > Again i am confused.
> > >
> > > /usr/bin/ld is linker at compilation time, at it works how i told in
> > > second part
> > > of my mail, (just try to compile it, it comes with binutils,
> > > ftp.kernel.org/pub/linux/devel/binutils).
> > >
> > > /lib/d-2.2.X.so  is what you are talking about.
> > > So should i think os an hack to ld-2.2.3.so ??
> >
> > The RH 7.1 comes with:
> > :~# ld --version
> > GNU ld 2.10.91
> > Copyright 2001 Free Software Foundation, Inc.
> > This program is free software; you may redistribute it under the terms
> > of
> > the GNU General Public License.  This program has absolutely no
> > warranty.
> >   Supported emulations:
> >    elf_i386
> >    i386linux
> >    elf_i386_glibc21
> Ok, this is the linker for compilation time, it
> is not related to the loader for shared libraries. You can even remove
> /usr/bin/ld, and the system will run anyway binaries, but you will not be
> able to link compiled objects.
> try a find for the directory ldscripts or for those files,

It appears that Redhat has eliminated much of this. If I run updatedb,
then locate, I find there is no instance of "ldscripts". Nor is there an
instance of "i386linux" or "i386coff" that can be seen by locate. So I
made it a wider locate, and tried for any instance of just "86linux" or
"86coff", these also do not exist. Apparently Redhat has completely
changed linking (looking at a backup of an older RH 6.2, these do exist,
so I suspect the change at around 7.0).

> 
> elf_i386.x    elf_i386.xs   i386coff.xn  i386linux.xbn
> elf_i386.xbn  elf_i386.xu   i386coff.xr  i386linux.xn
> elf_i386.xn   i386coff.x    i386coff.xu  i386linux.xr
> elf_i386.xr   i386coff.xbn  i386linux.x  i386linux.xu
> 
> you could not find the *coff* ones....
> those are the configuration file (unproper definition, i ask
> excuse for my english), for /usr/bin/ld you are running
> doing ld --version.
> >
> > The glibc rpm is version 2.2.2-10.
> >
> > >
> > > to see how it works loock at /usr/bin/ldd, it's an interesting script.
> > >
> > > I can understand why old glibc 2.1 is not isered in the directories
> > > where ldconfig has to loock to create its db for loader, but there should
> > > be a corrispective /usr/i386-(redhat/glibc2.2???)-linux/ (with its
> > > subdirectories)
> > > for glibc 2.2, since it is necessary at compilation
> > > time.
> >
> > There is *no* /usr/i386-xxx except for:
> > /usr/i386-glibc21-linux/
> name could be different, just could you e-mail the output for
> the command tree inside of /usr?

The entire tree would be quite large. Are you looking only for
directories (this would be a much smaller listing)? It might even
challenge the maximum size an ISP allows before filtering it:
16632 directories, 258120 files

> >
> > No glibc22 version exists.
> >
> > > This do not change the problem which is related to /lib/ld-2.2.X.so.
> > > doing a strings /lib/ld-2.XXX
> > > you will find also
> > >
> > > info[19]->d_un.d_val == sizeof (Elf32_Rel)
> > > info[20]->d_un.d_val == 17
> > > /lib/
> > > /usr/lib/
> > > {ORIGIN}
> > > {PLATFORM}
> > > expand_dynamic_string_token
> > > dl-load.c
> >
> > "i686" is visible on a line by itself, but so are i386, i486, and i586.
> this is another thing...
> > The full path of /lib/i686/ is not mentioned anywhere. So it looks like
> > strings of /lib/ld-2* does not offer any hints as to how the i686
> > subdirectory is being chosen without it being specified anywhere else. I
> > think this will end up just being one of those mysteries, and the boot
> > software coder will have to find some non-trivial workaround. It sounds
> > like the /lib/i686/ path was hardcoded in the linker when it was
> > compiled, which means there are no simple config file checks.
> and then they compiled ALL other binaries from scratch with new linker,
> passing /lib/i686/libc.so.6 explivitally, or changing the script
> /usr/lib/libc.so?

No ldscripts on the system. Through locate and awk, I can guarantee
there is also only one ld on the system, /usr/bin/ld. It sounds like
they did compile all other binaries from scratch, passing /lib/i686/
explicitly.

> 
> boh! I do not know, and I am not thinking I am going to install a Red Hat
> right now (simply it is not suitable for my needs, it is a great
> distribution, of course, but it is not what my users need).
> 
> want my suggestion?
> upgrade to glibc 2.2.3 and to binutils 2.11.90.0.19 building
> them from sources against 2.4.X kernel includes. And you wil see if it
> works how you would expect.

Part of my reason for running Redhat 7.1 (aside from liking it's X11
support) is that I expect to be testing a lot of software for
compatibility against this particular distribution. I might upgrade my
glibc from 2.2.2 to 2.2.3, but not for a while, due to the same reasons.

As far as this particular problem goes, I am trying to help the author
of some general boot disk utilities find a good way to automatically
detect (through perl scripts) the correct libc configuration. Telling
users of the software that Redhat 7.1 is not supported is not an option,
regardless of why it is a problem. What it will probably end up becoming
is a mechanical script to test for the existence of /lib/{uname -a}/,
and if it exists, adding it to the boot disk ld.so.conf, or some other
arrangement that does similar.

D. Stimits, stimits@idcomm.com

> 
> Luigi
> 
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/

Re: Is this part of newer filesystem hierarchy?

[Luigi Genoni]

On Sat, 23 Jun 2001, D. Stimits wrote:
> > > The RH 7.1 comes with:
> > > :~# ld --version
> > > GNU ld 2.10.91
> > > Copyright 2001 Free Software Foundation, Inc.
> > > This program is free software; you may redistribute it under the terms
> > > of
> > > the GNU General Public License.  This program has absolutely no
> > > warranty.
> > >   Supported emulations:
> > >    elf_i386
> > >    i386linux
> > >    elf_i386_glibc21
> > Ok, this is the linker for compilation time, it
> > is not related to the loader for shared libraries. You can even remove
> > /usr/bin/ld, and the system will run anyway binaries, but you will not be
> > able to link compiled objects.
> > try a find for the directory ldscripts or for those files,
>
> It appears that Redhat has eliminated much of this. If I run updatedb,
> then locate, I find there is no instance of "ldscripts". Nor is there an
> instance of "i386linux" or "i386coff" that can be seen by locate. So I
> made it a wider locate, and tried for any instance of just "86linux" or
> "86coff", these also do not exist. Apparently Redhat has completely
> changed linking (looking at a backup of an older RH 6.2, these do exist,
> so I suspect the change at around 7.0).
glad to know this, i do wonder how does /usr/bin/ld work for red hat.
to my old mentality this seems red hat is going out of any resonable
standard.
>
> > >
> > > There is *no* /usr/i386-xxx except for:
> > > /usr/i386-glibc21-linux/
> > name could be different, just could you e-mail the output for
> > the command tree inside of /usr?
>
> The entire tree would be quite large. Are you looking only for
> directories (this would be a much smaller listing)? It might even
> challenge the maximum size an ISP allows before filtering it:
> 16632 directories, 258120 files
It is my own curiosity. yes if you could send me the direcotory tree of
your /usr. Just to see. Actually i know none using red hat 7.X to whom i
could ask to check, they are all slackware addicted.
>
>
> No ldscripts on the system. Through locate and awk, I can guarantee
> there is also only one ld on the system, /usr/bin/ld. It sounds like
> they did compile all other binaries from scratch, passing /lib/i686/
> explicitly.
mmm!
Again I am confused. how can the linker work?
>
>
> As far as this particular problem goes, I am trying to help the author
> of some general boot disk utilities find a good way to automatically
> detect (through perl scripts) the correct libc configuration. Telling
> users of the software that Redhat 7.1 is not supported is not an option,
> regardless of why it is a problem. What it will probably end up becoming
> is a mechanical script to test for the existence of /lib/{uname -a}/,
> and if it exists, adding it to the boot disk ld.so.conf
I would not be so scared, if you set a LD_PRELOAD_LIBRARY to
/lib/libc.so.6, you willse any binary will run anyway, because it would be
too mutch
if the same libc stripped would not run library, and they HAVE to mantein
a libc.so.6 linside of /lib, otherway this would be too mutch against
a resonable standard.
I would be happy if some guy from red hat could explain what is going on.

Luigi Genoni

Re: Is this part of newer filesystem hierarchy?

[Alan Cox]

> glad to know this, i do wonder how does /usr/bin/ld work for red hat.
> to my old mentality this seems red hat is going out of any resonable
> standard.

It works like /usr/bin/ld on any other platform I know of

> if the same libc stripped would not run library, and they HAVE to mantein
> a libc.so.6 linside of /lib, otherway this would be too mutch against
> a resonable standard.

bash-2.04$ ls -l /lib/libc.so.6  
lrwxrwxrwx    1 root     root           13 May 14 16:46 /lib/libc.so.6 -> libc-2.2.2.so

I don't follow the discussion here. 

Re: Is this part of newer filesystem hierarchy?

[Luigi Genoni]

The point was that Stimits says that on its Red Hat 7.1 he has no
ldscripts directory, and so no files like elf_i386.x and so on.
I was just surprised, since i know thay are all necessary to /usr/bin/ld
to work.

Then he was alo wondering why he has
two libc
/lib/libc.so.6 and /lib/i686/libc.so.6, one is tripped and the other
contains debug symbols.
I can figure why, but he adfirms that /lib/i686 is not included in
/etc/ld.so.conf, there is no preload configured, but this is the directory
used by the loader to find the libc to load.

I have to red hat installed, so i was trying to figure out how things are
working on new releases (my last red hat was 6.2 when i was working at red
hat Italy).

Bests
Luigi

On Sun, 24 Jun 2001, Alan Cox wrote:

> > glad to know this, i do wonder how does /usr/bin/ld work for red hat.
> > to my old mentality this seems red hat is going out of any resonable
> > standard.
>
> It works like /usr/bin/ld on any other platform I know of
>
> > if the same libc stripped would not run library, and they HAVE to mantein
> > a libc.so.6 linside of /lib, otherway this would be too mutch against
> > a resonable standard.
>
> bash-2.04$ ls -l /lib/libc.so.6
> lrwxrwxrwx    1 root     root           13 May 14 16:46 /lib/libc.so.6 -> libc-2.2.2.so
>
> I don't follow the discussion here.
>

Re: Is this part of newer filesystem hierarchy?

[Alan Cox]

> The point was that Stimits says that on its Red Hat 7.1 he has no
> ldscripts directory, and so no files like elf_i386.x and so on.
> I was just surprised, since i know thay are all necessary to /usr/bin/ld
> to work.

> two libc
> /lib/libc.so.6 and /lib/i686/libc.so.6, one is tripped and the other
> contains debug symbols.


Ok that I dont know. The dynamic linker has changed a fair bit over time and
I don't know enough about it to help

Re: Is this part of newer filesystem hierarchy?

[Luigi Genoni]

Yes, but i followed its development till now, and those file are still
present, belive me, when i do compile latest versions.
I am doing beta test of it when i have time,
and i think i tried all versions from 2.7.... times, sometimes sending bug
reports.

On Sun, 24 Jun 2001, Alan Cox wrote:

> > The point was that Stimits says that on its Red Hat 7.1 he has no
> > ldscripts directory, and so no files like elf_i386.x and so on.
> > I was just surprised, since i know thay are all necessary to /usr/bin/ld
> > to work.
>
> > two libc
> > /lib/libc.so.6 and /lib/i686/libc.so.6, one is tripped and the other
> > contains debug symbols.
>
>
> Ok that I dont know. The dynamic linker has changed a fair bit over time and
> I don't know enough about it to help
>

Re: Is this part of newer filesystem hierarchy?

[D. Stimits]

Alan Cox wrote:
> 
> > glad to know this, i do wonder how does /usr/bin/ld work for red hat.
> > to my old mentality this seems red hat is going out of any resonable
> > standard.
> 
> It works like /usr/bin/ld on any other platform I know of
> 
> > if the same libc stripped would not run library, and they HAVE to mantein
> > a libc.so.6 linside of /lib, otherway this would be too mutch against
> > a resonable standard.
> 
> bash-2.04$ ls -l /lib/libc.so.6
> lrwxrwxrwx    1 root     root           13 May 14 16:46 /lib/libc.so.6 -> libc-2.2.2.so
> 
> I don't follow the discussion here.

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. So far the two possibilities seem to be that either the
linker was precompiled to look in the subdirectory, or else when the
linker looks at /lib/ it also recursively checks other directories (this
doesn't seem likely). The reason why it matters is because it is
confusing some custom boot floppy creation software. The original author
of that software is looking for a means to make it work correctly with
RH 7.1. The manual way for it to avoid confusion is to cd to the mount
point of the ramdisk which it builds up, into its lib directory, and sym
link the contents of the i686 subdirectory into the main lib directory.
But the original software does interesting things like checking what
ld.so.conf has, and checking what environment variables are set, but
since none of those provide any clues, the automated means remains
broken for now. Probably the next step will be manually testing for the
existence of /lib/{uname -m}/, and if it exists, sym linking it to /lib/
(these are actually relative to the mount point of the ramdisk during
creation). The boot system is designed as a customized bootdisk creation
that automatically detects various dependencies of a highly customized
linux install.

It still remains to be seen how it is that /lib/i686/libc.so.6 is used
in place of /lib/libc.so.6 (which could be deleted and RH 7.1 wouldn't
care...very strange).

D. Stimits, stimits@idcomm.com

> 
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/

Re: Is this part of newer filesystem hierarchy?

[Keith Owens]

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.

Re: Is this part of newer filesystem hierarchy?

[Luigi Genoni]

OK, i could even figure that, my interest was mainly about binutils and
/usr/bin/ld, which should refer to ldscript directory to work.
At less, it ever did so since 9 years on my at home compiled versions,
(actually 2.11.90.0.17).


On Sun, 24 Jun 2001, Keith Owens wrote:

> 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.
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
>