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

[Rolf Eike Beer]

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?

Eike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://public.kitware.com/pipermail/cmake-developers/attachments/20111003/253b5bef/attachment.sig>