Bruce Dubbs wrote: > Bryan Kadzban wrote: > >>>> 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... > > I think the issue is that the library can be updated without rebuilding the > app.
Right, that's why /lib/ld-linux.so.2 (when it's loading libraries) looks up the soname built into the executable, not the full name. It's also why you have to change your library's soname if your ABI ever changes in an incompatible way. :-) > For instance, I have: > > lrwxrwxrwx 1 root root 18 Aug 16 14:31 libncursesw.so.5 -> > libncursesw.so.5.7 > -rwxr-xr-x 1 root root 396804 Aug 16 17:09 libncursesw.so.5.7 > > If I updated to libncursesw.so.5.8, the link also updates, but the packages > that > use libncursesw.so.5 can still find it via the symlink. The link updates when you (next) run ldconfig, but yes. Libraries like readline or programs like bash, which were built using libncursesw.so (or in LFS's case, were built using libncurses.so but redirected to libncursesw.so via the script), and which had "libncursesw.so.5" built into their DT_NEEDED section, will find libncursesw.so.5.8 instead of .5.7 at runtime, using this new link. > As an experiment, you might want to try renaming some of those symlinks and > see > if ldd still finds the library. I don't want to do it though. If you remove the libncursesw.so.5 link, then bash won't start. (Or Python, via readline.) Of course, current bash processes will be fine, since the real file is still there. OTOH, trying to "gcc file1.c -o file1 -lncurses" (or -lncursesw) should still work fine. (Though that depends on where the .so symlinks point. If they point at the soname symlink, then they won't work, and we tend to do that in some cases at least. But if they point at the final target lib, then linking will work fine.) If you remove libncurses.so and/or libncursesw.so, then you can't compile dynamically (gcc above falls back to using libncurses.a or libncursesw.a, or fails altogether if you remove those as well), but you can still start up a new bash. (Or Python, or whatever else.)
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
