reduced link interface: some link breakage possible

[Richard Moore]

On Mon, Dec 15, 2008 at 11:51 PM, Matthew Woehlke
<mw_triad at users.sourceforge.net> wrote:
> Richard Moore wrote:
>>
>> On Mon, Dec 15, 2008 at 11:22 PM, Matthew Woehlke wrote:
>>>
>>> Richard Moore wrote:
>>>>
>>>> On Mon, Dec 15, 2008 at 10:20 PM, Alexander Neundorf 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?
>
> Why wouldn't it? You already linked it to libbar, that's the point I was
> trying to make.

I don't know - I am unsure of the way library dependencies work on all
our supported platforms - that's why I asked.

>
>> 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?
>
> The original post clearly stated that you may "get some undefined symbols
> when linking".

Surely that's against our compatibility policies then? AFAIK this is
supposed to be guaranteed through a major release cycle.

Cheers

Rich.