[CMake] INSTALL(EXPORT) does not honor LINK_INTERFACE_LIBRARIES?

[Rolf Eike Beer]

Am Donnerstag, 31. März 2011, 15:26:31 schrieb Brad King:
> On 03/31/2011 09:14 AM, Rolf Eike Beer wrote:
> > See below. Looks like the only way to prevent this is to set
> > LINK_INTERFACE_LIBRARIES to empty for every lib that uses the static
> > lib.
> > Which may be a good idea anyway as that transitive linking is harmful.
> 
> CMake has always done said transitive linking for historical reasons.
> The default behavior cannot change now.  It is not necessarily harmful
> if the static library objects are built with -fPIC and are not all
> absorbed into the shared library that initially links it.

set(DONT_DO_SILLY_LEGACY_OVERLINKING true)? ;)

> The documented way to turn off transitive linking is to set the
> LINK_INTERFACE_LIBRARIES property.  Once that is done then install(EXPORT)
> will not complain about the transitive static libraries anymore.  However,
> it *will* complain about the *shared* libraries for the reason I explained
> in my earlier response to this thread.

I start to get the point ;)

> On 03/29/2011 05:36 PM, Rolf Eike Beer wrote:
> > Am Dienstag, 29. März 2011, 09:41:36 schrieb Brad King:
> >> CMake running in an outside application needs to know these private
> >> runtime dependencies.  It needs them ensure that the application link
> >> line is generated such that the linker can find the transitive
> >> dependencies (e.g. -rpath-link) of the public library.
> > 
> > No, why should it?
> 
> See the sample script below.  CMake needs to know where bar's transitive
> dependencies are installed so that it can pass the right thing to
> -rpath-link. This is is how IMPORTED_LINK_DEPENDENT_LIBRARIES is used and
> why the install(EXPORT) command needs all the targets in the export.
> 
> Since one target can be installed to multiple locations, or accidentally
> not at all, the install(TARGETS) for 'foo' must list the same EXPORT as
> the install(TARGETS) for 'bar' so that CMake can associate the right copy
> of the dependency.

Isn't the rpath stored inside those shared libraries? So every shared library 
(and the executable itself) know where it's own dependencies are located?

Ok, at the end that actually makes sense. But since I'm installing every 
library to the same directory on Un*x wouldn't it be possible to just drop out 
all those libraries somehow? It will not matter on Windows anyway as that 
doesn't support rpath. So private shared libraries will not show up if the 
rpath would already be set to the directory anyway?

Just to get that right: these targets will show up when importing to another 
build but CMake will only use them to get the rpath right. It will not link 
against those targets so the transitive dependencies will not be propageted?

Eike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://www.cmake.org/pipermail/cmake/attachments/20110402/85369aa2/attachment.pgp>