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