>On Thu, 17 Oct 2013 10:20:47 -0500 >Bruce Dubbs <[email protected]> wrote: > > Aleksandar Kuktin wrote: > >> On Wed, 16 Oct 2013 22:52:00 -0500 > >> Bruce Dubbs <[email protected]> wrote: > >> > >> alex lupu wrote: > >>> Not pretty. Apparently, a sizable dead space waiting to be > >>> reclaimed. > >> > >> Actually, the files needed are the .so and .so.0 links and, of > >> course, the file they point to. The .so file is what the linker > >> looks for and the loader looks for the .so.0 file. You can delete > >> the rest. > > > > Isn't it that the run-time linker uses whatever *.so was pointing > > to at build time? > > The build time linker embeds what the .so file says to use. > Generally it's the so.# value. Devs can then update the library if > the ABI doesn't change, but the internals do. > > If the ABI changes, then the library version (so.#) needs to be > incremented. It is valid to have something like: > > lib.so -> lib.so.2 > lib.so.2 -> lib.so.2222 > lib.so.1 -> lib.so.1111 > lib.so.1111 > lib.so.2222 > > Apps can then use whatever was current when built, but new apps will > use the .2 version. > > -- Bruce
Aha. So the file (*.so after deref.) itself has its name printed on its forehead, the build linker puts that name into the executable (or library, if the library built links to other libraries) and then the run-time linker uses that to find the *.so# file needed. Okay, thanks. :) -- You don't need an AI for a robot uprising. Humans will do just fine.
signature.asc
Description: PGP signature
-- http://linuxfromscratch.org/mailman/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
