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, [e-mail]

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