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 _______________________________________________ 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