Messages in this thread | | | Date | Sun, 24 Jun 2001 01:42:48 +0200 (CEST) | From | Luigi Genoni <> | Subject | Re: Is this part of newer filesystem hierarchy? |
| |
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
- 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/
| |