Am Montag, 3. Oktober 2011, 07:59:45 schrieb Clinton Stimpson: > On Oct 3, 2011, at 3:25 AM, Rolf Eike Beer wrote: > > Am Samstag, 1. Oktober 2011, 22:51:55 schrieb Clinton Stimpson: > >> On Oct 1, 2011, at 4:48 PM, Rolf Eike Beer wrote: > >>> 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. > >> > >> Can you consider this example as a demonstration for why cmake wants > >> information about foo in the exports file even though its an internal > >> detail? > > > > Yes, I can. This wouldn't have been relevant for me, as all the > > libraries were installed to the same directory. > > Did you see the second example in another email shortly after this one, > where the libraries were in the same directory? Using some newer Linux > distros or the --enable-new-dtags linker flag shows the issue even if the > libraries are in the same directory. I wonder if there is another way for > cmake to get the information it needs for the export file without giving > the internal targets.
Well, for the KDE part I let Alex wrestle with what needs to be exported. For my original example I do not really care anymore as this code isn't mine anymore. Regarding the --enable-new-dtags this is basically a new format to store the same stuff in ELF as far as I understand what I can find. So the question is why enabling this changes behaviour? Eike
signature.asc
Description: This is a digitally signed message part.
-- 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
