Re: Stupid library ABI question
On Wed, Jan 10, 2007 at 09:36:28AM -0800, Kevin B. McCarty wrote:
> > 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?
Yes, it does.
> 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?
Yes, it will.
> > 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).
Sounds like a perfectly reasonable course of action to me. Anything opening
your lib with dlopen() looking for Xbae and Xaw symbols deserves to be taken
out back and shot, twenty times over. :)
> 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?
They'll still work just fine. This actually happens quite frequently with
private symbols that were never meant to be exported as part of the
library's ABI and have never been included in the published API.
Cheers,
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
vorlon@debian.org http://www.debian.org/
Reply to: