[CMake] INSTALL_NAME_DIR on MacOSX

[James Bigler]

Hi,

On Oct 24, 2007, at 12:57 PM, Alan W. Irwin wrote:

> On 2007-10-24 12:16-0600 James Bigler wrote:
>
>> So, I had a dynamic library with the following:
>>
>> SET_TARGET_PROPERTIES(narfencode
>>  PROPERTIES BUILD_WITH_INSTALL_RPATH OFF
>>  INSTALL_NAME_DIR "@executable_path"
>>  )
>>
>> When I compile it I get this:
>>
>> /usr/bin/c++    -dynamiclib -headerpad_max_install_names  -o  
>> libnarfencode.dylib -install_name /Users/bigler/cibc/ 
>> cpack_install/ opt/libnarfencode.dylib "CMakeFiles/narfencode.dir/ 
>> encode.o"
>>
>> Note that the -install_name is the local build directory.  This  
>> works well for when I run the binary out of the build directory,  
>> but if I run "make install" it doesn't relink the library with the  
>> *installed* -install_name.
>>
>> I believe it should be relinking the library during installation  
>> to match where it will be after it's installed.
>>
>> Note that if I set it to ON, it works for the installed version  
>> (and may not work for the build tree version).
>
> Here is what works for us:
>
> if(CMAKE_SYSTEM_NAME STREQUAL "Darwin")
>   # No rpath on Darwin. Setting it will only cause trouble.
> else(CMAKE_SYSTEM_NAME STREQUAL "Darwin")
>   option(USE_RPATH "Use -rpath when linking libraries, executables"  
> ON)
> endif(CMAKE_SYSTEM_NAME STREQUAL "Darwin")
>
> if(USE_RPATH)
>   set_target_properties(
>   plplot${LIB_TAG}
>   PROPERTIES
>   SOVERSION ${plplot_SOVERSION}
>   VERSION ${plplot_VERSION}
>   INSTALL_RPATH "${LIB_INSTALL_RPATH}"
>   INSTALL_NAME_DIR "${LIB_DIR}"
>   )
> else(USE_RPATH)
>   set_target_properties(
>   plplot${LIB_TAG}
>   PROPERTIES
>   SOVERSION ${plplot_SOVERSION}
>   VERSION ${plplot_VERSION}
>   INSTALL_NAME_DIR "${LIB_DIR}"
>   )
> endif(USE_RPATH)
>
> For completeness I left in the SOVERSION and VERSION properties we  
> set for
> the PLplot principal library, but the only difference between the two
> alternatives is INSTALL_RPATH "${LIB_INSTALL_RPATH}"
>
...
> I hear from PLplot OS X users that the above CMake logic also works  
> well on
> that platform both for the build tree (where I assume CMake  
> automatically
> does not use rpath for the Darwin case) and install tree (where  
> because
> of the above logic CMake does not use rpath for the Darwin case).

This would work if one had the exact path the library would be in  
while compiling.  Unfortunately, there needs a flexible mechanism to  
install the binaries in different places.

Macs provide a mechanism to have relative rpaths via @executable_path  
and @loader_path.  This provides a mechanism to install libraries in  
a path relative to where the binary will be.  This is how Application  
Bundles work.

http://developer.apple.com/documentation/DeveloperTools/Conceptual/ 
DynamicLibraries/Articles/DynamicLibraryDesignGuidelines.html#// 
apple_ref/doc/uid/TP40002013-SW21

I guess my other option is to build the libraries directly into the  
framework, so that the build tree mirrors the structure of how it  
will be installed.

Thanks,
James