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 -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake