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

[Michael Wild]

On 16. Jul, 2009, at 14:45, Eric Noulard wrote:

> 2009/7/16 Hendrik Sattler <post at hendrik-sattler.de>:
>> Zitat von Michael Wild <themiwi at gmail.com>:
>>>>
>>>> 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.
>>
>> So maybe the proper value can be made available as variable? Or  
>> direct
>> support in cmake with some boolean variable?
>
> Small message to say that I would find this a good feature request.
>
>> Like:
>> CMAKE_RELATIVE_RPATH_SUPPORTED true/false
>> CMAKE_RELATIVE_RPATH_PREFIX:
>>  Linux: "$ORIGIN"
>>  MacOS: "@executable_path"
>> Anything else?

Honestly, I don't think this is necessary. What is so complicated  
about this?

set(CMAKE_INSTALL_NAME_DIR "@executable_prefix/../lib")
set(CMAKE_INSTALL_RPATH "$ORIGIN/../lib")

>
> May be there is some equivalent on Windows platform too
> http://msdn.microsoft.com/en-us/library/ms682586(VS.85).aspx
> [just pointing the link, I'm really no windows expert and ....
> don't want to become one :-) ]

Seriously, that platform is just plain broken if you ask me.  
__declspec(dllimport), __declspec(dllexport)?! What were they  
thinking? And DLL-exported C++ template instantiations with member  
templates simply don't work. Sometimes I marvel at why so many people  
go trough the pains of writing software for such a broken system...

>
> May be worth a Wiki update too (even before the feature is
> requested/implemented)
> http://www.cmake.org/Wiki/CMake_RPATH_handling

ACK

Michael