On Monday, October 03, 2011 08:50:23 am Rolf Eike Beer wrote: > 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? >
The difference is whether the rpaths accumulate/propagate to additional dependent shared libraries and across dlopen(). -- Clinton Stimpson Elemental Technologies, Inc Computational Simulation Software, LLC www.csimsoft.com -- 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
