reduced link interface: some link breakage possible

[Richard Moore]

On Mon, Dec 15, 2008 at 11:22 PM, Matthew Woehlke
<mw_triad at users.sourceforge.net> wrote:
> Richard Moore wrote:
>>
>> On Mon, Dec 15, 2008 at 10:20 PM, Alexander Neundorf <neundorf at kde.org>
>> wrote:
>>>
>>>  2.) You are probably using symbols from some library which you don't
>>> link to
>>> directly, but which was dragged in via one of the other libraries you
>>> link
>>> to, and these "dragged in" libraries have now been mostly removed.
>>> In this case, add these missing libraries explicitely to the
>>> TARGET_LINK_LIBRARIES() command.
>>> (because: less dependencies for packages, faster startup, some advantages
>>> in
>>> keeping binary compatiblity).
>>
>> How does this affect binary compatibility? It sounds like this might break
>> it.
>
> Why would it affect BC? As I understand, this means that:
>
> - libfoo links with libbar
> - libcow links with libfoo and uses functions from libbar
> - this used to work, now it won't
>
> Previously this would work because telling cmake you wanted libfoo would
> know that libfoo needs libbar, and would therefor implicitly link libcow
> with both libfoo and libbar. Now you need to specify that you are using
> libbar.
>
> The only "some advantages in keeping BC" I can come up with is that libcow
> would previously expect libbar regardless if it used it or not, which means
> that if libfoo is rebuilt without libbar and libbar is dropped, you have a
> problem. In which case, this change doesn't break BC, and reduces the
> chances of a future library removal causing a BC break.
>
> That said, it's entirely possible I missed something ;-).

b/c means that a binary distribution of an app linked against one
version of a set of libraries will continue to operate against future
ones. In your example, will an app that was compiled using libcow and
relying on the implicit linkage of libbar continue to work?

The source compatibility issue here is will a 3rd party app that was
setup to work the way things work before still work as expected? eg.
will the amarok 2.0 source release from last week work correctly with
this change?

Cheers

Rich.