Messages in this thread | | | Date | Sat, 23 Jun 2001 19:09:12 -0600 | From | "D. Stimits" <> | Subject | Re: Is this part of newer filesystem hierarchy? |
| |
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/ - 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/
| |