reduced link interface: some link breakage possible

[Matthew Woehlke]

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.

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

-- 
Matthew
Please do not quote my e-mail address unobfuscated in message bodies.
-- 
Me: wtf?? "#warning This is temporary since Dec 2000". Seven-year 
"temporary" code?
Mathieu Chouinard: Sounds like the correct definition of temporary :)