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

[Chris Wolf]

On 8/15/10 12:43 PM, Michael Wild wrote:
> 
> On 15. Aug, 2010, at 13:22 , Chris Wolf wrote:
> 
>>
>>
>>
>>>>
>>>> No, the two mechanisms are fundamentally different.
>>>>
>>>> On Linux the RPATH is a search path (think LD_LIBRARY_PATH) that is encoded into the binary. The linker 
>>>> only embeds the library name, no directory information. The loader then first searches these directories 
>>>> for the linked libraries, and then proceeds to search LD_LIBRARY_PATH and the directories defined in ld.conf.
>>>>
>>>> On Mac OS X, the install_name is a file name encoded into the library itself. When another binary is linked 
>>>> against this library, the linker hard-codes this file name into the binary, no matter what the actual location 
>>>> of the library is. The loader then tries to load that library using the hard-coded install_name from the binary, 
>>>> and only if that fails, uses DYLD_FALLBACK_LIBRARY_PATH.
>>>>
>>>> I hope this clarifies things a bit.
>>>>
>>>> Michael
>>>
>>> Actually, I would say that the Darwin dynamic loader behavior is a super-set of the Linux dynamic loader.
>>> You can set RPATHs in an executable via the linker option "-rpath /tmp/bar" and instead of single
>>> colon-delimited path, you just specify multiple "-rpath /some/path" options.
>>>
>>> Then you can set the install_name on the dependent shared libraries to "@rpath/mylib.dylib" which is used 
>>> to locate the shared library via the rpath(s) in the executable.  This would be the same behavior
>>> as Linux:
>>>
>>> See:   http://bit.ly/bNert1
>>>       http://developer.apple.com/mac/library/documentation/Darwin/Reference/ManPages/man1/dyld.1.html
>>>       http://bit.ly/csQGqb
>>>
>>> However, I am not necessarily advocating doing that, since that is not the convention used
>>> to deliver simple (i.e. not framework or bundle or plugins) apps and libraries.  All I am
>>> suggesting is that it might be helpful if CMake would present the same usage for specifying 
>>> linkage behavior for Linux and Darwin, even if the underlying executable->library lookup 
>>> mechanism is different.  Either that, or fix up the documentation to point out were things
>>> diverge.
>>>
>>>  -Chris
>>
>> I just thought I'd modify your greetings example to show how one could use rpath's, Linux-style.
>> It's a bit of a tangent to the discussion because: it's unconventional on Mac; it won't work with fat
>> binaries.
>>
>> You can see the added rpath of the executable with "otool -l".
>>
>>   -Chris
>> <greetings.tgz>
> 
> 
> Yes, agreed. But RPATH is a relatively recent addition to OS X (10.5, I think), so you have to enable this depending on 
> CMAKE_OSX_DEPLOYMENT_TARGET (and hope that some user doesn't fool you by setting the 
> MACOSX_DEPLOYMENT_TARGET environment variable or adding -mmacosx-version-min to CMAKE_{C,CXX}_FLAGS). 
> So, I'm not sure what the default behavior of CMake should be for Mac OS X, especially since most developers 
> don't know about RPATH on Mac OS X, and certainly don't expect it.
> 
> Michael
> 

I agree and that's why I previously mentioned I don't advocate using RPATH at all for normal apps, 
since that's not the convention for normal apps/dylibs on Mac. I just pointed out that's it's 
possible and desirable for the special case of relocatable plugins.

Best thing, I think, is to add a small footnote to this particular section of the CMake RPATH
handling:   http://www.cmake.org/Wiki/CMake_RPATH_handling#Always_full_RPATH

...and mention that for OSX you would also need to set CMAKE_INSTALL_NAME_DIR as Michael 
demonstrated in his example.

  -Chris