On Sa., 1. Okt. 2011 18:40:09 CEST, Alexander Neundorf <neund...@kde.org> wrote:
> If library bar internally uses symbols from foo, > it needs to link against foo. Correct. > But if bar doesn't expose symbols from foo in its > interface, and my executable hello links against bar, it doesn't also > have to be linked against foo. This saves startup time and other things. > Packagers also like that. No, you got something wrong here. Packagers hate that. That's exactly the reason why e.g. Fedora and others introduced -Wl,no-unneeded (or how that's called) in their default linker flags. If your hello needs foo and bar, and is only linked to bar because that one is already linked against foo, that your package will not work any longer if you replace foo 1.0 with foo 1.1 which is totally binary compatible but doesn't need foo internally any longer because your hello then misses symbols on startup. This is called unterlinking of hello and should be avoided whereever possible. The opposite is overlinking and that was what I tried to avoid: my hello did not need any symbols from foo itself, so I wanted to get rid of them (which worked by forcing the implicit dependencies to empty). But CMake still did not want to allow me to export the bar target without also exporting foo even if the linkage to foo was only an internal detail and the user was not even allowed to use foo directly. Eike -- 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://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
