[CMake] rpath problems with kdevplatform

[Alexander Neundorf]

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).

> > > 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.

It shouldn't be empty, it is set in FindKDE4Internal.cmake around line 1000:

if (UNIX)
   ...
   if (APPLE)
      set(CMAKE_INSTALL_NAME_DIR ${LIB_INSTALL_DIR})
   else (APPLE)
      # add our LIB_INSTALL_DIR to the RPATH (but only when it is not one of
      # the standard system link
      # directories listed in CMAKE_PLATFORM_IMPLICIT_LINK_DIRECTORIES) and
      # use the RPATH figured out by cmake when compiling

      list(FIND CMAKE_PLATFORM_IMPLICIT_LINK_DIRECTORIES "${LIB_INSTALL_DIR}"
           _isSystemLibDir)
      if("${_isSystemLibDir}" STREQUAL "-1")
         set(CMAKE_INSTALL_RPATH "${LIB_INSTALL_DIR}")
      endif("${_isSystemLibDir}" STREQUAL "-1")

      set(CMAKE_SKIP_BUILD_RPATH FALSE)
      set(CMAKE_BUILD_WITH_INSTALL_RPATH FALSE)
      set(CMAKE_INSTALL_RPATH_USE_LINK_PATH TRUE)
   endif (APPLE)
endif (UNIX)

Is LIB_INSTALL_DIR empty ?
It shouldn't, it's set earlier in the same file.

Alex