[CMake] rpath problems with kdevplatform

[Andreas Pakulat]

On 29.06.10 23:21:10, Alexander Neundorf wrote:
> On Monday 28 June 2010, Andreas Pakulat wrote:
> > 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_RPAT
> > >H
> > >
> > > 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.
> 
> The thing here is that e.g. barplugin in the build tree automatically gets the 
> RPATH inside the buildtree, e.g. to libbar. But if it doesn't link to 
> anything outside the buildtree, the install RPATH will be empty.
> If libbar would be already installed e.g. in /opt/kdev/lib/, and libbar would 
> be linked against it, and CMAKE_INSTALL_RPATH_USE_LINK_PATH is 
> enabled, /opt/kdev/lib/ would end up in the install RPATH.
> 
> But if libbar is part of the same project (as barplugin) this is not the case.
> 
> One could argue whether it would make sense to automatically add the install 
> directory of libraries of the same project to the install RPATH if 
> CMAKE_INSTALL_RPATH_USE_LINK_PATH is enabled.
> But currently that's not the case, so the lib install dir has to be added 
> manually to the INSTALL_RPATH if necessary (see code below).

IMHO that would make sense indeed, building a plugin in the same project
is not really different from building it in a separate project (from a
users point of view).

> > > 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.
> 
> It shouldn't be empty, it is set in FindKDE4Internal.cmake around line 1000:

Ah, apparently thats also been patched out by Debian, didn't see that
when comparing with the original file...

Re-adding that line does work.

Andreas

-- 
You will always get the greatest recognition for the job you least like.