[CMake] Weirdness with shared library, RPATH policy on MacOS
Chris Wolf
cw10025 at gmail.com
Fri Aug 13 12:33:07 EDT 2010
On 8/13/10 11:21 AM, Michael Wild wrote:
>
> On 13. Aug, 2010, at 16:32 , Chris Wolf wrote:
>
>>
>>
>> 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
>
> http://www.cmake.org/cmake/help/cmake-2-8-docs.html#prop_tgt:INSTALL_NAME_DIR
> http://www.cmake.org/cmake/help/cmake-2-8-docs.html#variable:CMAKE_INSTALL_NAME_DIR
>
> Sometimes hitting the "find next" button really helps...
>
> Michael
>
>
Although I appreciate you taking time to reply to my inquiries,
this particular response is not really helpful - those two links you refer too
merely summarize what the first link I referred to says.
Have you actually built shared libraries on MacOS with CMake? If so, maybe an example
of yours would be more helpful.
Thanks,
-Chris
More information about the CMake
mailing list