Re: Stupid library ABI question
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" <kmccarty@Princeton.EDU> 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 <kmccarty@princeton.edu> Physics Department
WWW: http://www.princeton.edu/~kmccarty/ Princeton University
GPG: public key ID 4F83C751 Princeton, NJ 08544
Reply to: