[CMake] Weirdness with shared library, RPATH policy on MacOS

[Chris Wolf]

On 8/13/10 10:23 AM, Chris Wolf wrote:
> 
> 
> On 8/13/10 9:29 AM, Michael Wild wrote:
>>
>> On 13. Aug, 2010, at 15:25 , Chris Wolf wrote:
>>
>>>
>>> I have confirmed that the RPATH handling, as documented here:
>>>
>>> http://www.cmake.org/Wiki/CMake_RPATH_handling
>>>
>>> Is only accurate for the Linux case and *NOT* for MacOS.  
>>>
>>> Here is the summary of my findings:
>>>
>>> "Default RPATH":
>>> http://www.cmake.org/Wiki/CMake_RPATH_handling#Default_RPATH_settings
>>>
>>> link in build: full build path rpath
>>> link on install: installed executable will have no rpath
>>>
>>> Linux: yes - works as documented, must set LD_LIBRARY_PATH for installed
>>>             executable to find shared lib in non-standard install dir
>>>
>>> MacOS: no -  installed executable rpath is still set to full build rpath,
>>>             (was supposed to be empty rpath) 
>>>             must set LD_LIBRARY_PATH for installed
>>>             executable to find shared lib in non-standard install dir
>>>
>>>
>>>
>>> "Always Use RPATH":
>>> http://www.cmake.org/Wiki/CMake_RPATH_handling#Always_full_RPATH
>>>
>>> Linux: yes - works as documented, build executable uses build rpath, 
>>>       installed executable uses installed rpath
>>>
>>> MacOS: no - installed executable rpath is still set to full build rpath
>>>       (was supposed to be installed lib rpath)
>>>       must set LD_LIBRARY_PATH for installed
>>>       executable to find shared lib in non-standard install dir
>>>
>>>
>>>
>>> "No relinking and full RPATH for the install tree":
>>> http://www.cmake.org/Wiki/CMake_RPATH_handling#No_relinking_and_full_RPATH_for_the_install_tree
>>>
>>>
>>> Linux: yes - works as documented; to run executable in build tree, must 
>>>       set LD_LIBRARY_PATH=. 
>>>
>>> MacOS: no - executable has no RPATH for build tree, (as expected)
>>>       although executable finds library in current working directory (build)
>>>       installed executable *also* has no RPATH; (was supposed to be installed lib rpath)
>>>       must set DYLD_LIBRARY_PATH for installed
>>>       executable to find shared lib in non-standard install dir.
>>>       otool -L shows no RPATH in both executable cases
>>>
>>>
>>> I would like to get scenario #2 or #3 working on MacOS.
>>>
>>> Thanks,
>>>
>>>  -Chris
>>>
>>
>> AFAIK RPATH settings are irrelevant on Mac OS X, since it is always used. 
>> And the relevant target property is INSTALL_NAME_DIR, initialized by the variable CMAKE_INSTALL_NAME_DIR.
>>
>> Michael
> 
> When you write, "RPATH settings are irrelevant on Mac OS X, since it is always used.",
> does "it" refer to "RPATH"?  If so then how could the settings be irrelevant?
> 
> If the RPATH settings were irrelevant on MacOS, then the documentation should say so
> and/or CMake should block, or flag as error, application of these settings in the MacOS case.
> But I'm thinking that these settings *are* relevant since they do have some effect on
> the executable lib search behavior.
> 
> As I mentioned, I tried setting both INSTALL_NAME_DIR and CMAKE_INSTALL_NAME_DIR and these did not 
> have any effect.  I have not found documentation for them other then forum postings, such as:
> 
> http://www.cmake.org/pipermail/cmake/2006-June/009758.html
> http://www.cmake.org/pipermail/cmake/2006-October/011527.html
> etc...
> 
> 

I want to amend my last statement: I have not found documentation for 
INSTALL_NAME_DIR and CMAKE_INSTALL_NAME_DIR in CMake's *manual* - 
actually, there is a small paragraph, which mentions these settings
without explaining how to use them:

http://www.cmake.org/cmake/help/cmake-2-8-docs.html#command:set_target_properties

  -Chris