[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Stupid library ABI question



Neil Williams <linux@codehelp.co.uk> writes:

> 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.

Actualy I think if libfoo is linked against libbar then the ld will
load libbar and libfoo and then have all the symbols. So it should
work in some cases.

>> Does libfoo.so need to have its soname bumped, since it no longer
>> provides B() and C()?
>
> I'd say yes.

Me too, for correctness sake at a minimum.

>> Or can it keep the same soname since it still
>> indirectly provides B() and C() via its new dependency on libbar.so?
>
> It is not indirect because the application uses B and C, so the
> application needs to link directly against B and C or symbols will not
> be resolved. Indirect means that libfoo needs E() and F() from libbar
> but does not expose either E or F as public symbols. (I'm assuming here
> that there is are sufficient applications using publicly exposed symbols
> such that each symbol is used at least once.)

The applications also need to Build-Depends on libbar-dev so that it
tracks api changes in libbar and in case libfoo-dev drops its depends
on libbar-dev at some point.

> 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.

Libfoo can provide 'B() { return barB(); }' and 'C() { return barC();
}' stubs to keep the size down if the code realy is compatible.

MfG
        Goswin



Reply to: