On 8/13/10 10:23 AM, Chris Wolf wrote: > > > On 8/13/10 9:29 AM, Michael Wild wrote: >> >> On 13. Aug, 2010, at 15:25 , Chris Wolf wrote: >> >>> >>> I have confirmed that the RPATH handling, as documented here: >>> >>> http://www.cmake.org/Wiki/CMake_RPATH_handling >>> >>> Is only accurate for the Linux case and *NOT* for MacOS. >>> >>> Here is the summary of my findings: >>> >>> "Default RPATH": >>> http://www.cmake.org/Wiki/CMake_RPATH_handling#Default_RPATH_settings >>> >>> link in build: full build path rpath >>> link on install: installed executable will have no rpath >>> >>> Linux: yes - works as documented, must set LD_LIBRARY_PATH for installed >>> executable to find shared lib in non-standard install dir >>> >>> MacOS: no - installed executable rpath is still set to full build rpath, >>> (was supposed to be empty rpath) >>> must set LD_LIBRARY_PATH for installed >>> executable to find shared lib in non-standard install dir >>> >>> >>> >>> "Always Use RPATH": >>> http://www.cmake.org/Wiki/CMake_RPATH_handling#Always_full_RPATH >>> >>> Linux: yes - works as documented, build executable uses build rpath, >>> installed executable uses installed rpath >>> >>> MacOS: no - installed executable rpath is still set to full build rpath >>> (was supposed to be installed lib rpath) >>> must set LD_LIBRARY_PATH for installed >>> executable to find shared lib in non-standard install dir >>> >>> >>> >>> "No relinking and full RPATH for the install tree": >>> http://www.cmake.org/Wiki/CMake_RPATH_handling#No_relinking_and_full_RPATH_for_the_install_tree >>> >>> >>> Linux: yes - works as documented; to run executable in build tree, must >>> set LD_LIBRARY_PATH=. >>> >>> MacOS: no - executable has no RPATH for build tree, (as expected) >>> although executable finds library in current working directory (build) >>> installed executable *also* has no RPATH; (was supposed to be >>> installed lib rpath) >>> must set DYLD_LIBRARY_PATH for installed >>> executable to find shared lib in non-standard install dir. >>> otool -L shows no RPATH in both executable cases >>> >>> >>> I would like to get scenario #2 or #3 working on MacOS. >>> >>> Thanks, >>> >>> -Chris >>> >> >> AFAIK RPATH settings are irrelevant on Mac OS X, since it is always used. >> And the relevant target property is INSTALL_NAME_DIR, initialized by the >> variable CMAKE_INSTALL_NAME_DIR. >> >> Michael > > When you write, "RPATH settings are irrelevant on Mac OS X, since it is > always used.", > does "it" refer to "RPATH"? If so then how could the settings be irrelevant? > > If the RPATH settings were irrelevant on MacOS, then the documentation should > say so > and/or CMake should block, or flag as error, application of these settings in > the MacOS case. > But I'm thinking that these settings *are* relevant since they do have some > effect on > the executable lib search behavior. > > As I mentioned, I tried setting both INSTALL_NAME_DIR and > CMAKE_INSTALL_NAME_DIR and these did not > have any effect. I have not found documentation for them other then forum > postings, such as: > > http://www.cmake.org/pipermail/cmake/2006-June/009758.html > http://www.cmake.org/pipermail/cmake/2006-October/011527.html > etc... > >
I want to amend my last statement: I have not found documentation for INSTALL_NAME_DIR and CMAKE_INSTALL_NAME_DIR in CMake's *manual* - actually, there is a small paragraph, which mentions these settings without explaining how to use them: http://www.cmake.org/cmake/help/cmake-2-8-docs.html#command:set_target_properties -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
