Thanks everyone who answered so far! Unfortunately some of the answers (Steve Langasek's vs. Neil Williams') seem directly opposed :-) I'd like to try to understand this better since I really know very little technical detail about how the runtime linker works.
Neil Williams wrote: > On Mon, 08 Jan 2007 11:19:40 -0800 > "Kevin B. McCarty" <[EMAIL PROTECTED]> wrote: > >> Hello, >> >> I have a dumb library ABI question. Suppose I maintain a library >> libfoo.so that has public functions A(), B() and C(). Now there is a >> new release in which libfoo.so only provides A(), but it is now (newly) >> dynamically linked against libbar.so, which has public functions B() and >> C() with interfaces identical to the old B() and C() in the old version >> of libfoo.so. > > How will applications linked against the original libfoo be able to > locate the symbols B and C? As these are called directly from the > application, the application would have to be linked against libbar. > > You are adding a new dependency to these applications, libbar. Doesn't the linker on Linux search dependencies recursively? Suppose there is some application "do_stuff" that was originally linked against the old libfoo.so (the one that provided B() and C() itself). If "objdump -x do_stuff | grep NEEDED" gives libfoo.so, and "objdump -x libfoo.so | grep NEEDED" gives libbar.so (only on the new libfoo.so) then wouldn't do_stuff, now being indirectly linked against libbar.so[*], still have B() and C() in its list of known symbols? [*] That is, "ldd do_stuff" will now output both libfoo.so and libbar.so > A better solution for libfoo, IMHO, is for libbar to use barB() and barC > () then libfoo can retain B() and C() until such time as all > applications have migrated to barB and barC. Understood, but this isn't really an option for me. The issue is that I maintain a library [*] whose source includes embedded code from old versions of libXbae and libXaw, and I've just been notified of this fact. I would really rather remove that code and link it dynamically against external versions of those libraries (for obvious security and maintainability reasons). Not being upstream of libXbae or libXaw, I really can't change the name of the functions in question in those libraries. [*] libpawlib2-lesstif Debian package, if anyone's interested Upstream of my library (Cernlib maintainers) only ships static libraries, and the shared library support is hacked in by me. So I have complete control over the soversion, but of course I'd rather not bump it if I can get away without doing so. Let me ask another question that will possibly show the amount of my ignorance :-) If a library stops shipping certain symbols (so that the soversion *should* definitely be bumped, but *isn't*), but no applications or other libraries actually use those symbols, then what happens to programs built against the old library but now using the new one? a) They segfault because the new version of the library is missing symbols b) They work properly because they don't use the missing symbols c) Something in between (?) There are no other interface changes in the library (i.e. function APIs and structs that still exist all stay the same). best regards, -- Kevin B. McCarty <[EMAIL PROTECTED]> Physics Department WWW: http://www.princeton.edu/~kmccarty/ Princeton University GPG: public key ID 4F83C751 Princeton, NJ 08544 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
