[CMake] Shared libraries cannot be found after deploying a CPack package

[Hendrik Sattler]

Am Mittwoch 15 Juli 2009 17:20:25 schrieb Frank Stappers:
> With the help of CPack we would like to make packages. Currently,
> we can make packages for MAC OSX (DMG, TSGZ, GZ) and UNIX (RPM, DEB,
> STGZ, GZ). For static builds (so no shared libraries) these packages
> can be deployed in any directory, without any problems. For builds that
> use shared libraries, the binaries inside the packages do not seem to
> work, if they are deployed in a path other than the $CMAKE_INSTALL_PREFIX.
>
> When inspecting the RPATH's binaries, they all point to the
> CMAKE_INSTALL_RPATH (${CMAKE_INSTALL_PREFIX}/lib/mcrl2) where
> the libraries can be found. For RPMs and DEBs, that have a fixed
> deployment path, this will not be a problem. We simply
> set the CMAKE_INSTALL_PREFIX to the path where we want to the deploy the
> package and the problem is "solved".
>
> Deploying DMG, STGZ and GZ packages turns to be a bit more problematic,
> because a user is free to chose a custom deployment path (which is most
> likely not the ${CMAKE_INSTALL_PREFIX}$). As a result, all binaries that
> use shared libraries cannot be executed, because they point to
> non-existing paths.
>
> So the question is as follows: Is it possible for CPack to create
> packages that can be installed in a directory that deviates from
> the $CMAKE_INSTALL_PREFIX? If so, which variables/modules do I need
> set/execute?
>
> Thanks in advance for any help,

You could force the RPATH to something like documented in the ld.so manpage 
(linux):
$ORIGIN
ld.so understands the string $ORIGIN (or equivalently ${ORIGIN}) in an rpath 
specification to mean the directory containing  the  application  executable.  
Thus,  an application located in somedir/app could be compiled with gcc -Wl,-
rpath,’$ORIGIN/../lib’ so that it finds an associated shared library in 
somedir/lib no matter where somedir is located in the directory hierarchy.

HS