<div class="gmail_quote">On Sun, Aug 15, 2010 at 1:25 AM, Chris Wolf <span dir="ltr"><<a href="mailto:cw10025@gmail.com">cw10025@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div><div></div><div class="h5"><br>
<br>
On 8/14/10 4:01 PM, Michael Wild wrote:<br>
><br>
> On 14. Aug, 2010, at 18:26 , Chris Wolf wrote:<br>
><br>
>><br>
>><br>
>> On 8/14/10 10:31 AM, Michael Wild wrote:<br>
>>><br>
>>> On 14. Aug, 2010, at 15:13 , Chris Wolf wrote:<br>
>>><br>
>>>><br>
>>>><br>
>>>> On 8/14/10 3:35 AM, Michael Wild wrote:<br>
>>>>><br>
>>>>> On 13. Aug, 2010, at 20:58 , Michael Wild wrote:<br>
>>>>> [...]<br>
>>>>>><br>
>>>>>> Sure, <a href="http://repo.or.cz/w/freefoam.git/shortlog/refs/heads/pu" target="_blank">http://repo.or.cz/w/freefoam.git/shortlog/refs/heads/pu</a>, but it's pretty complex...<br>
>>>>>><br>
>>>>>> Michael<br>
>>>>><br>
>>>>> Attached is a tiny project which works for me on both Linux and Mac.<br>
>>>>><br>
>>>>> Michael<br>
>>>>><br>
>>>><br>
>>>> That's awesome! Thanks so much. From your example, and looking at the documentation:<br>
>>>> <a href="http://www.cmake.org/Wiki/CMake_RPATH_handling#Always_full_RPATH" target="_blank">http://www.cmake.org/Wiki/CMake_RPATH_handling#Always_full_RPATH</a><br>
>>>><br>
>>>> ...I can see the difference now - you are setting CMAKE_INSTALL_NAME_DIR.<br>
>>>> (which is not needed or used on Linux/ELF)<br>
>>>><br>
>>>> What I had been trying to do along these lines was a per-target setting:<br>
>>>><br>
>>>> set_target_properties(usbDynamic PROPERTIES INSTALL_NAME_DIR "/tmp/local/lib")<br>
>>>><br>
>>>> -=or=-<br>
>>>><br>
>>>> set_target_properties(usbDynamic PROPERTIES INSTALL_RPATH "/tmp/local/lib/libusb-1.dylib"")<br>
>>>><br>
>>>> -=or=-<br>
>>>><br>
>>>> set_target_properties(usbDynamic PROPERTIES<br>
>>>> INSTALL_RPATH "/tmp/local/lib/libusb-1.dylib"<br>
>>>> INSTALL_NAME_DIR "/tmp/local/lib")<br>
>>>><br>
>>>> None of those were working for me.<br>
>>>><br>
>>>> I will incorporate your setting in my project.<br>
>>>><br>
>>>> Thanks,<br>
>>>><br>
>>>> -Chris<br>
>>><br>
>>><br>
>>> Aaaah, I see. The INSTALL_RPATH should have been /tmp/local/lib. And RPATH is only a Linux thing, while install_name is a Mac OS X thing ;-)<br>
>>><br>
>>> Michael<br>
>><br>
>> Actually, "/tmp/local/lib" is just for testing - my intention is to use "/usr/local/lib".<br>
>><br>
>> Also RPATH on Mac OSX is no different then Linux, SunOS, etc. - only the mechanism to change it is.<br>
>><br>
>> For example, CMake appears to use perform direct modification of ELF-formatted binaries,<br>
>> apparently to avoid relinking upon installation (i.e. running the generated cmake_install.cmake)<br>
>><br>
>> It does this via the undocumented FILE(RPATH_CHANGE,.., FILE(RPATH_REMOVE,... routines.<br>
>> which are called indirectly via<br>
>> cmInstallTargetGenerator::PostReplacementTweaks/cmInstallTargetGenerator::AddChrpathPatchRule<br>
>><br>
>> For some reason (maybe to accommodate frameworks) instead of polymorphically implementing<br>
>> cmSystemTools::ChangeRPath and cmSystemTools::RemoveRPath to handle the ELF *or* Darwin<br>
>> cases (which would have allowed AddChrpathPatchRule to work for ELF *and* Darwin)<br>
>> - a separate piece of logic was implemented for PostReplacementTweaks called,<br>
>> cmInstallTargetGenerator::AddInstallNamePatchRule, which invokes the OSX utility<br>
>> "install_name_tool" to change the RPATH in shared libraries and executables.<br>
>><br>
>> The way I see it (and I could be wrong) there is divergence between the logic of<br>
>> AddChrpathPatchRule (ELF RPATH logic) and AddInstallNamePatchRule (Darwin RPATH logic)<br>
>><br>
>> Ideally, if cmSystemTools::ChangeRPath and cmSystemTools::RemoveRPath were<br>
>> polymorphic for ELF and Darwin, you would only need AddChrpathPatchRule and not<br>
>> AddInstallNamePatchRule, such that the FILE(RPATH_CHANGE,.., FILE(RPATH_REMOVE<br>
>> routines would function the same for ELF and Darwin and the generated<br>
>> "cmake_install.cmake" would look the same for both of these platforms - as a result,<br>
>> the documented behavior (<a href="http://www.cmake.org/Wiki/CMake_RPATH_handling" target="_blank">http://www.cmake.org/Wiki/CMake_RPATH_handling</a>)<br>
>> would be identical for ELF and Darwin cases.<br>
>><br>
>> Well, that's my two cents...<br>
>><br>
>> Thanks again for your help,<br>
>><br>
>> -Chris<br>
><br>
> No, the two mechanisms are fundamentally different.<br>
><br>
> On Linux the RPATH is a search path (think LD_LIBRARY_PATH) that is encoded into the binary. The linker<br>
> only embeds the library name, no directory information. The loader then first searches these directories<br>
> for the linked libraries, and then proceeds to search LD_LIBRARY_PATH and the directories defined in ld.conf.<br>
><br>
> On Mac OS X, the install_name is a file name encoded into the library itself. When another binary is linked<br>
> against this library, the linker hard-codes this file name into the binary, no matter what the actual location<br>
> of the library is. The loader then tries to load that library using the hard-coded install_name from the binary,<br>
> and only if that fails, uses DYLD_FALLBACK_LIBRARY_PATH.<br>
><br>
> I hope this clarifies things a bit.<br>
><br>
> Michael<br>
<br>
</div></div>Actually, I would say that the Darwin dynamic loader behavior is a super-set of the Linux dynamic loader.<br>
You can set RPATHs in an executable via the linker option "-rpath /tmp/bar" and instead of single<br>
colon-delimited path, you just specify multiple "-rpath /some/path" options.<br>
<br>
Then you can set the install_name on the dependent shared libraries to "@rpath/mylib.dylib" which is used<br>
to locate the shared library via the rpath(s) in the executable. This would be the same behavior<br>
as Linux:<br>
<br>
See: <a href="http://bit.ly/bNert1" target="_blank">http://bit.ly/bNert1</a><br>
<a href="http://developer.apple.com/mac/library/documentation/Darwin/Reference/ManPages/man1/dyld.1.html" target="_blank">http://developer.apple.com/mac/library/documentation/Darwin/Reference/ManPages/man1/dyld.1.html</a><br>
<a href="http://bit.ly/csQGqb" target="_blank">http://bit.ly/csQGqb</a><br>
<br>
However, I am not necessarily advocating doing that, since that is not the convention used<br>
to deliver simple (i.e. not framework or bundle or plugins) apps and libraries. All I am<br>
suggesting is that it might be helpful if CMake would present the same usage for specifying<br>
linkage behavior for Linux and Darwin, even if the underlying executable->library lookup<br>
mechanism is different. Either that, or fix up the documentation to point out were things<br>
diverge.<br>
<font color="#888888"><br>
-Chris<br>
</font><div><div></div><div class="h5"><br>
<br>
<br>
<br>
_______________________________________________<br>
Powered by <a href="http://www.kitware.com" target="_blank">www.kitware.com</a><br>
<br>
Visit other Kitware open-source projects at <a href="http://www.kitware.com/opensource/opensource.html" target="_blank">http://www.kitware.com/opensource/opensource.html</a><br>
<br>
Please keep messages on-topic and check the CMake FAQ at: <a href="http://www.cmake.org/Wiki/CMake_FAQ" target="_blank">http://www.cmake.org/Wiki/CMake_FAQ</a><br>
<br>
Follow this link to subscribe/unsubscribe:<br>
<a href="http://www.cmake.org/mailman/listinfo/cmake" target="_blank">http://www.cmake.org/mailman/listinfo/cmake</a><br>
</div></div></blockquote></div><br><br>One thing that would be useful, for sure, for future googlers: a link from the Wiki articles on RPATH to this very email thread on the CMake mailing list...... Could somebody who knows where all those Wiki articles are add a link to this thread....??<br>
<br>Thanks,<br>David<br><br>