On 8/14/10 10:31 AM, Michael Wild wrote: > > On 14. Aug, 2010, at 15:13 , Chris Wolf wrote: > >> >> >> On 8/14/10 3:35 AM, Michael Wild wrote: >>> >>> On 13. Aug, 2010, at 20:58 , Michael Wild wrote: >>> [...] >>>> >>>> Sure, http://repo.or.cz/w/freefoam.git/shortlog/refs/heads/pu, but it's >>>> pretty complex... >>>> >>>> Michael >>> >>> Attached is a tiny project which works for me on both Linux and Mac. >>> >>> Michael >>> >> >> That's awesome! Thanks so much. From your example, and looking at the >> documentation: >> http://www.cmake.org/Wiki/CMake_RPATH_handling#Always_full_RPATH >> >> ...I can see the difference now - you are setting CMAKE_INSTALL_NAME_DIR. >> (which is not needed or used on Linux/ELF) >> >> What I had been trying to do along these lines was a per-target setting: >> >> set_target_properties(usbDynamic PROPERTIES INSTALL_NAME_DIR >> "/tmp/local/lib") >> >> -=or=- >> >> set_target_properties(usbDynamic PROPERTIES INSTALL_RPATH >> "/tmp/local/lib/libusb-1.dylib"") >> >> -=or=- >> >> set_target_properties(usbDynamic PROPERTIES >> INSTALL_RPATH "/tmp/local/lib/libusb-1.dylib" >> INSTALL_NAME_DIR "/tmp/local/lib") >> >> None of those were working for me. >> >> I will incorporate your setting in my project. >> >> Thanks, >> >> -Chris > > > 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 ;-) > > Michael
Actually, "/tmp/local/lib" is just for testing - my intention is to use "/usr/local/lib". Also RPATH on Mac OSX is no different then Linux, SunOS, etc. - only the mechanism to change it is. For example, CMake appears to use perform direct modification of ELF-formatted binaries, apparently to avoid relinking upon installation (i.e. running the generated cmake_install.cmake) It does this via the undocumented FILE(RPATH_CHANGE,.., FILE(RPATH_REMOVE,... routines. which are called indirectly via cmInstallTargetGenerator::PostReplacementTweaks/cmInstallTargetGenerator::AddChrpathPatchRule For some reason (maybe to accommodate frameworks) instead of polymorphically implementing cmSystemTools::ChangeRPath and cmSystemTools::RemoveRPath to handle the ELF *or* Darwin cases (which would have allowed AddChrpathPatchRule to work for ELF *and* Darwin) - a separate piece of logic was implemented for PostReplacementTweaks called, cmInstallTargetGenerator::AddInstallNamePatchRule, which invokes the OSX utility "install_name_tool" to change the RPATH in shared libraries and executables. The way I see it (and I could be wrong) there is divergence between the logic of AddChrpathPatchRule (ELF RPATH logic) and AddInstallNamePatchRule (Darwin RPATH logic) Ideally, if cmSystemTools::ChangeRPath and cmSystemTools::RemoveRPath were polymorphic for ELF and Darwin, you would only need AddChrpathPatchRule and not AddInstallNamePatchRule, such that the FILE(RPATH_CHANGE,.., FILE(RPATH_REMOVE routines would function the same for ELF and Darwin and the generated "cmake_install.cmake" would look the same for both of these platforms - as a result, the documented behavior (http://www.cmake.org/Wiki/CMake_RPATH_handling) would be identical for ELF and Darwin cases. Well, that's my two cents... Thanks again for your help, -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
