[cmake-developers] Setting the link interface and dependencies in one command

[Clinton Stimpson]

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
> > > 
> > > <neundorf at 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