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

Michael Wild themiwi at gmail.com
Thu Jul 16 03:45:01 EDT 2009


On 16. Jul, 2009, at 9:26, Frank Stappers wrote:

> Hendrik Sattler wrote:
>> 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
>
> Thanks for the provided solution.
> Setting CMAKE_INSTALL_RPATH  to "$ORIGIN/../lib/mcrl2" solves the
> problem, as the binaries are located in "${CMAKE_INSTALL_PREFIX}/bin/ 
> mcrl2".
>

On Mac you can set the INSTALL_NAME_DIR property (or the  
CMAKE_INSTALL_NAME_DIR variable) to something starting with  
@executable_path, to the same effect as above.

Michael



More information about the CMake mailing list