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

[Chris Wolf]

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