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

[Michael Wild]

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