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
_______________________________________________
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
