[CMake] rpath problems with kdevplatform

[Andreas Pakulat]

On 28.06.10 08:44:35, Brad King wrote:
> Andreas Pakulat wrote:
> > On 26.06.10 13:26:29, Andreas Pakulat wrote:
> >> Ping? Any further ideas on this? Could someone at least point me to the
> >> source code in cmake that decides wether to add RPATH_REMOVE or
> >> RPATH_REPLACE to the cmake_install.cmake file?
> 
> Look at "cmInstallTargetGenerator::AddChrpathPatchRule".  Its job is
> to generate the install-time script to fix up the RPATH in the installed
> binary.  The default is *no* RPATH, unless the INSTALL_RPATH target
> property is set:
> 
>   http://www.cmake.org/cmake/help/cmake-2-8-docs.html#prop_tgt:INSTALL_RPATH
> 
> Elsewhere in this thread (at least on the kde list) you mention this
> seems to be working for some targets and not others.  Look for where
> the INSTALL_RPATH gets set on the targets where it is working.

Let me clarify, I have two projects: kdevplatform and kdevelop. Both
have multiple targets, in particular:

kdevplatform
 - libfoo
 - libbar
 - fooplugin
 - barplugin

kdevelop
 - anotherplugin
 - someexe

Now libbar links against libfoo, fooplugin and barplugin both link again
libfoo and libbar. someexe and anotherplugin too.

When I now build kdevplatform I get "Removed runtime path" for each
installed library/plugin. Whereas doing the same in kdevelop shows "Set
runtime path of", i.e. the rpath of all binaries are adjusted to use the
install dir.

Both projects are being installed to the same prefix, namely
$HOME/kdevelop using -DCMAKE_INSTALL_PREFIX.

> > Found it already, I've patched a cmake checkout here to give some
> > diagnostic output and looking at the differences its apparent that for
> > kdevplatform the installation prefix is not added to the
> > "OrderRuntimeSearchPath" list in cmComputeLinkInformation, but this is
> > done for kdevelop targets.
> 
> This has nothing to do with RPATH_REMOVE or RPATH_CHANGE calls during
> installation.  The only time this code would be used with install-tree
> information is during the "relink" step used on non-ELF platforms used
> to build a new RPATH into the binaries for installation.

Well, as I said above I see those Removing/Changing messages which
apparently (according to my grep) are coming from cmake_install.cmake.
And thats how I found the places in the source code of CMake that
computes the runtime path.

> > The reason seems to be that when building kdevplatform there are no
> > libraries in the install-prefix that the to-be-built targets link
> > against. So it seems that this is rather a cmake bug, hence I'm cc'ing
> > to the cmake list (and including all the quotes).
> >
> > @CMake-List readers: Am I right that cmake simply should add the
> > install-prefix to the ORderRuntimeSearchPath at some point during
> > initialization?
> 
> No, this is intentional behavior.  CMake sets the RPATH up in the build
> tree to help the binary find its dependencies at runtime.  If it does
> not link to anything in <prefix>/lib then there will be no RPATH entry
> for it.

But it does, except that the relevant libs/plugins are built as part of
the project.

> > That should help in this case (I didn't test this yet)
> 
> As I said above it won't affect the install tree.  See the INSTALL_RPATH
> target property.

That property is not set (and the global variable CMAKE_INSTALL_RPATH)
is empty too, nonetheless one project gets rpath info set in the
installed plugins/executable the other one doesn't.

Andreas

-- 
You will be misunderstood by everyone.