[CMake] Weirdness with shared library, RPATH policy on MacOS

[Chris Wolf]

On 8/13/10 3:47 AM, Michael Wild wrote:
> 
> On 12. Aug, 2010, at 22:37 , Chris Wolf wrote:
> 
>> I have a project which creates a shared library and a utility which uses this
>> shared library.  I would like to be able to run the utility within the build
>> tree and also from the final install directory.  I can do this, it works,
>> but the path hard-coded path in the executable is always the build tree path.
>>
>> The default RPATH policy works for this:
>>
>> http://www.cmake.org/Wiki/CMake_RPATH_handling#Default_RPATH_settings
>>
>> Unfortunately the build directory path gets "baked in" to the executable, 
>> even at install time.  If I run "make clean", the executable still seems
>> to find the library even though the copy in the build tree is deleted.  
>> However, running "otool -L" (same as "ldd" on Linux) on the executable 
>> reveals that the RPATH is still in the build tree rather then the install path:
>>
>> $ otool -L lsusb 
>> lsusb:
>> 	/Users/cwolf/src/cmaketest/libusb-1.0.8/libusb/build/libusb-1.0.dylib (compatibility version 0.0.0, current version 1.0.8)
>> 	/usr/lib/libgcc_s.1.dylib (compatibility version 1.0.0, current version 1.0.0)
>> 	/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 111.0.0)
>>
>>
>> This setting shows which libraries are actually loading at runtime:
>>
>> $ export DYLD_PRINT_LIBRARIES=true
>> clozaril-2:bin cwolf$ ./lsusb 
>> dyld: loaded: /private/tmp/local/bin/./lsusb
>> dyld: loaded: /tmp/local/lib/libusb-1.0.dylib
>> dyld: loaded: /usr/lib/libgcc_s.1.dylib
>> dyld: loaded: /usr/lib/libSystem.B.dylib
>> dyld: loaded: /System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation
>> dyld: loaded: /System/Library/Frameworks/IOKit.framework/Versions/A/IOKit
>> [...]
>>
>>
>> As can be seen, the executable is dynamically linking with the install directory
>> (/tmp/local/lib)
>>
>> The preceding is observed regardless of whether I use the default RPATH settings 
>> or if I use "Always Full RPATH":
>>
>>
>> http://www.cmake.org/Wiki/CMake_RPATH_handling#Always_full_RPATH
>>
>>
>> ...which supposedly relinks the executable upon
>> "make install" such that the RPATH is changed to the install path - but I don't
>> see that.
>>
>>
>> Any ideas?  
> 
> Did you set CMAKE_INSTALL_RPATH and CMAKE_INSTALL_NAME_DIR?
> 
> Michael
> 
> 

For CMAKE_INSTALL_RPATH - yes, both of the rpath policies I mention above set this:

http://www.cmake.org/Wiki/CMake_RPATH_handling#Default_RPATH_settings
http://www.cmake.org/Wiki/CMake_RPATH_handling#Always_full_RPATH

For CMAKE_INSTALL_NAME_DIR - I was not aware of that one, although I saw
INSTALL_NAME_DIR (no CMAKE_ prefix) documented as being MacOS-specific, so 
I had been setting that too (all along, to "/usr/local/lib") and that may
have been allowing the library to load from /ust/local/lib even though
otool -L was reporting the build tree location.

I will try CMAKE_INSTALL_NAME_DIR also now - thanks.

  -Chris