[CMake] INSTALL_NAME_DIR on MacOSX

[Mike Jackson]

On Oct 24, 2007, at 3:54 PM, James Bigler wrote:

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

I use a custom shell script that uses "install_name_tool" to adjust  
the install_path after compilation. For me this seems to be the least  
painful way to accomplish this. The support in CMake just does not  
work how I expect it to work (ie. like xcode). In that shell script  
(which gets configured by cmake) I also copy the library into the  
Application bundle and also set the install_names correctly in the  
built application. All kinda "kludgeish" to me.. but does work. I end  
up with a self contained Application that is portable across  
different macs.

Just my 2 cents. If you want copies of the shell scripts they are at:

http://titanium.imts.us/viewvc/Task_7/MXADataModel/Resources/ 
PackageMXALibsForOSXAppBundle.sh.in


-- 
Mike Jackson   Senior Research Engineer
Innovative Management & Technology Services