Is this part of newer filesystem hierarchy?

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)

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.

Quoted 15 lines · 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.

Quoted 9 lines

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.

Quoted 13 lines

~# 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

Quoted 8 lines

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

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

Quoted 32 lines · 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.

Quoted 15 lines · 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.

Quoted 9 lines

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:

Quoted 4 lines

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.

Quoted 2 lines

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?

Quoted 5 lines

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})

Quoted 21 lines

Quoted 13 lines

~# 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

Quoted 8 lines

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)

Quoted 8 lines

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

Quoted 8 lines

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);

Quoted 5 lines

(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, [email protected]

Quoted 8 lines

Luigi Genoni

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

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

Quoted 143 lines · D. Stimits

Quoted 32 lines · 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.

Quoted 15 lines · 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.

Quoted 9 lines

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:

Quoted 4 lines

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.

Quoted 2 lines

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?

Quoted 5 lines

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})

Quoted 21 lines

Quoted 13 lines

~# 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

Quoted 8 lines

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)

Quoted 8 lines

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

Quoted 8 lines

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);

Quoted 5 lines

(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, [email protected]

Quoted 8 lines

Luigi Genoni

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

Quoted 6 lines

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

Quoted 10 lines · 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 ??

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.

Quoted 9 lines

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.

Quoted 4 lines

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

Quoted 8 lines

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.

Quoted 13 lines · D. Stimits

Quoted 10 lines · 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 ??

The RH 7.1 comes with:

Quoted 11 lines

:~# 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.

Quoted 13 lines

The glibc rpm is version 2.2.2-10.

Quoted 9 lines

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.

Quoted 2 lines

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?

Quoted 16 lines

No glibc22 version exists.

Quoted 4 lines

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

Quoted 8 lines

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

Quoted 1 line

"i686" is visible on a line by itself, but so are i386, i486, and i586.

this is another thing...

Quoted 7 lines

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

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

Quoted 12 lines

Quoted 12 lines

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

Quoted 5 lines

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).

Quoted 6 lines

Quoted 4 lines

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 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.

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

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.

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.

Quoted 3 lines

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

Quoted 3 lines

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.

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.

Quoted 8 lines

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

Quoted 4 lines

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

Quoted 3 lines

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.

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

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.

Quoted 9 lines · D. Stimits

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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/