Is this a problem with cmake or with my setup?

[Alexander Neundorf]

On Wednesday 04 August 2010, Brad King wrote:
> On 08/03/2010 06:45 PM, Michael Jansen wrote:
> > 1. Where does that list after rpath-link come from?
>
> CMake computes it based on the known shared library implementation
> dependencies.  For targets built in the tree these come from their
> full list of libraries used for linking (not the link interface).
> For imported targets these come from a target property called
>
>   IMPORTED_LINK_DEPENDENT_LIBRARIES
>
> The property should be set when the imported target is created.
> CMake's install(EXPORT) command copies the shared library
> dependency information into the above property when exporting
> a shared library target.
>
> >From the above CMake constructs a list of full paths to the library
>
> files (sonames) that it knows must be found at link time.  It then
> inspects the directories containing these libraries for conflicts,
> constructs a constraint graph, and generates a safe order for the
> directories to be listed with the -rpath-link flag.
>
> > 2. How can i influence it's content?
>
> There is no direct interface for it.  One must give CMake enough
> information for the above automatic algorithm to work.  If all the
> libraries involved in linking every CMake-built shared library along
> the way were brought in as imported targets then it would work.
> However, this is not the case for the Qt libraries AFAIK.
>
> For a shared library target CMake distinguishes its link interface
> dependencies (or "link interface") from its link implementation
> dependencies (or "link implementation").  It computes the set of
> shared libraries that go in IMPORTED_LINK_DEPENDENT_LIBRARIES by
> identifying shared libraries in the target's link implementation
> but excluding those in the target's link interface.  The result
> is the set of "dependent libraries".
>
> In the default case the link interface is the same as the link
> implementation so the list of dependent libraries is empty. When
> LINK_INTERFACE_LIBRARIES is set (which happens in your case) then
> the list can be non-empty.  However, it will only every consist
> of the libraries from the link implementation that CMake *knows*
> are shared libraries.
>
> Currently the definition of "knows" is that the dependent library
> is a *target* (imported or built) and not just a file name.  One
> can see the code in CMake 2.8.2 in the file Source/cmTarget.cxx
> at lines 4222-4245:
>
> http://cmake.org/gitweb?p=cmake.git;a=blob;f=Source/cmTarget.cxx;h=45ba3584
>;hb=v2.8.2#l4207
>
> Note the TODO comment.  It does not recognize shared libraries
> by file name.  This causes your problem because the file
>
>   /path/to/kde4/trunk/support/libphoton.so
>
> does not end up in the list of known dependent libraries.
> Therefore it is not included in the above-mentioned ordering
> algorithm and /path/to/kde4/trunk/support does not end up in
> the -rpath-link option.
>
> Unfortunately implementing the TODO comment is non-trivial.  CMake
> must first recognize shared library full-path file names from the
> link implementation list.  Then for each shared library it finds
> it must also locate the full path to the file that will be loaded
> at runtime based on the *soname* of the library!  In simple cases

Wouldn't this mean to parse the ELF header, find all required shared libs, and 
look for them too ?
Also, I think you can't reliable figure out at build time which shared lib 
will be used at runtime. LD_LIBRARY_PATH may be set, /etc/ld.so.conf may be 
different, it could be executed on a different system, etc.

> the soname is the same as the library, or the library file is just
> a symlink to the soname, but in the worst-case we need to know
> and understand the library's ABI to parse out the soname.
>
> > 3. Do we have a problem with our LINK_INTERFACE by only being
> > able to specify which libs we need and not being able to
> > specify where WE took it from? KHTML needs phonon but it does
> > not tell me openly.
>
> The KHTML imported target *should* come with libphoton.so listed
> in the IMPORTED_LINK_DEPENDENT_LIBRARIES property.  It does not
> right now because
>
> - libphoton.so was not imported as a target when khtml was built
> - CMake did not recognize it as a runtime dependency of khtml
>   due to the lack of implementation at the above-mentioned TODO

Hmm, wouldn't we still have a problem ?
Qt has been built with phonon, and some parts of Qt most probably link against 
this phonon in qt/lib/.
khtml has been linked against phonon in kdesupport/lib/, and we'd like to use 
that one, since it is newer.

But, if cmake would have the full information, i.e. that Qt would like to have 
the one in qt/lib/, and that khtml the one in kdesupport/lib/, wouldn't we 
get a conflict then ?
Is maybe the whole situation just a mess with phonon being built as part of Qt 
and also independent from it ?

Alex