[CMake] Bad documentation of the LINK_INTERFACE_LIBRARIES property and other transitive linking topics

[Michael Wild]

On 11/23/2011 11:11 AM, Rolf Eike Beer wrote:
>> On 11/23/2011 10:25 AM, Alan W. Irwin wrote:
> 
>>> In sum, from this experiment it looks like I will have to set
>>> LINK_INTERFACE_LIBRARIES to empty for all PLplot library targets that
>>> depend on other library targets (e.g., B, C, D, and E, above, but _not_
>>> main or A) created by our build system to comprehensively turn off
>>> transitive linking and avoid overlinking that rpmlint is complaining
>>> about.
>>
>> Transitive linking is a tricky issue, especially if the new
>> --no-copy-dt-needed-entries default is active which means that if you
>> have e.g. a library A, a library B that links against A and an
>> executable C that uses symbols from both, A and B but only directly
>> links against B, you will get a linking error if --as-needed is enabled.
> 
> And the linker is absolutely right here: you have not linked against a
> library you used symbols from. This has always been broken and works only
> by accident. This should fail. This must fail. Setting
> LINK_INTERFACE_LIBRARIES to empty to allow the linker detect this is a
> good thing.
> 
>> However, CMake can't know for you whether C actually needs to be linked
>> against A, so it takes the safe route. The alternative would be to not
>> do it, but then you would need to explicitly link C against A. See
>> http://wiki.debian.org/ToolChain/DSOLinking for more details.
> 
> And that would be a good thing, too.
> 
> The rules are absolutely simple (leaving dynamic plugins and dlopen()
> stuff out): if you use a symbol from a library you have to link against
> that library. And I don't see any value in helping people to ignore even
> this absolutely basic rule of programming.
> 
> Yes, I remember those examples where LINK_INTERFACE_LIBRARIES are indeed
> needed to fix some obscure things with different paths to libraries and
> whatnot. But I still wait for the day where someone shows me a real world
> example of why this is needed :)
> 
> Eike

I agree with all that you said. In an ideal world. But changing that
behaviour would cause a lot of build failures in existing projects.

Michael