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

Rolf Eike Beer eike at sf-mail.de
Wed Nov 23 05:11:50 EST 2011


> 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


More information about the CMake mailing list