Bruce Dubbs wrote: > Randy McMurchy wrote: >> Bruce Dubbs wrote: >>> Bryan Kadzban wrote: >>> >>>> But we don't put *any* .so (or .a) files into /lib, because the only >>>> reason for /lib is to hold libraries that are required before /usr may >>>> be mounted (i.e. early bootscripts). And when you're compiling -- which >>>> is the only time .so or .a files are used -- /usr had better be mounted. >>>> :-) >>> Actually .so files are used any time a dynamically linked executable needs >>> them, >>> not just when 'compiling'. But I think you know that. >> Yeah, but dynamically linked executables never need them (unless of course >> the package only provides a .so or .a file. Typically, what is needed for >> dynamically linked packages are files such as libfile.so.1. That is why we >> leave libfile.so.1 and libfile.so.1.37 in /lib. >> >> So, actually, .so and .a files are really only needed at compile time for >> other packages. :-) > > OK, I was throwing the .so and the .so.1 files together. Since they are > generally only symlinks, it makes sense to keep them together.
Except I'm not sure it does, because they're used for different things. :-) The soname symlink (the one whose name is determined by the -Wl,-soname,XXXXX string at the library's compile time) is required at runtime, or the program won't start. The plain .so link is only needed at compile time. Unless I misunderstood what you mean by "keep them together"? I don't think it makes any sense to have both in /lib, since I tend to think of /lib as containing the bare minimum required to get /usr mounted... >>> Actually, I think we may have several unnecessary files in /lib. I'm not >>> sure >>> why libhistory >> Probably for the bash shell. > > Right. > >>> , libnss*, >> These are Glibc files used for resolving names, likely needed in single user >> mode. > > Ok. I just noticed an interesting thing about these files: > > -rwxr-xr-x 1 root root 27084 Aug 16 17:09 libnss_dns-2.10.1.so > lrwxrwxrwx 1 root root 20 Aug 16 12:53 libnss_dns.so.2 -> > libnss_dns-2.10.1.so > > Although they were installed as a part of the same build, the timestamps are > considerably different. It's true for a very old LFS build too. Hmm. I doubt your glibc install took four hours, so I'm guessing it isn't just that the symlink target was installed four hours before ldconfig was run. Actually, hang on; my current system's libnss_dns-2.4.so file is dated August 2006 (about when I did the glibc install), but libnss_dns.so.2 is dated August 19, this year. And its date doesn't change when I do an ldconfig, either. And *every* symlink in that directory is dated August 19? OK, I'm confused. :-) Looking at a (multilib, a mashing-together of LFS, DIY, and occasional input from CLFS-1.1.0) build I'm also working on, it appears that both files were created at the same time (well, one minute apart), on September 2. Hmm... This isn't really entirely relevant (I don't think), just very odd. >>> libpcre, >> Probably bash again. > > No. Looking at my newer build, the following are installed after the > initial > LFS build: > > lrwxrwxrwx 1 root root 12 Aug 30 13:51 X11 -> /etc/X11/mwm > From lesstif. Probably should be fixed in BLFS. > > -rwxr-xr-x 1 root root 189575 Aug 30 15:43 libpcre.so.0.0.1 > From pcre and documented in BLFS to be for grep. Makes sense.
signature.asc
Description: OpenPGP digital signature
-- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
