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

[Chris Wolf]

On 8/13/10 1:12 PM, Martin Costabel wrote:
> Chris Wolf wrote:
> []
>> Have you actually built shared libraries on MacOS with CMake?  If so,
>> maybe an example
>> of yours would be more helpful.
> 
> The following settings work for me when building vtk5.6 for Fink:
> 
>   -DCMAKE_INSTALL_NAME_DIR:STRING=/sw/lib/vtk56 \
>   -DCMAKE_BUILD_WITH_INSTALL_RPATH:BOOL=ON \
>   -DCMAKE_INSTALL_RPATH:STRING="${CMAKE_INSTALL_NAME_DIR}" \
>   -DVTK_USE_RPATH=ON
> 
> In this case, during build time, that is before running make, one needs
> to set something like
> 
>   export DYLD_LIBRARY_PATH=`pwd`/bin
> 
> so that the newly built libraries are found in the build tree, otherwise
> the executables look for them in the install directory.
> 
> In principle, a second method using
> 
>   CMAKE_BUILD_WITH_INSTALL_RPATH=OFF
> 
> should also be possible, in which case cmake should use the BUILD_RPATH
> during building and then, at installation time, use install_name_tool to
> change all RPATHs to their INSTALL value. In the case of VTK, this works
> for the dylibs and for some of the executables, but not for python
> modules. Therefore I prefer the first method where the RPATH is
> immediately set to its INSTALL value, both in the dylibs and, by
> inheritance, in the executables.
> 

Thanks Martin, this worked for me, as did Michael's demo - both using
CMAKE_INSTALL_NAME_DIR, which I missed. (or actually was trying to 
do via set_target_properties)

It's interesting that you had a problem with this approach and python
modules - I had a similar issue and ending up statically linking the 
module because I had two releases of the same shared library on the system.

I'm thinking to revisit the problem after learning more about various 
shared library search policies under OSX.

  -Chris