[CMake] Problem linking dynamic libraries on MacOSX

[Michael Wild]

On 7. Apr, 2010, at 12:40 , Frank Stappers wrote:

> Hello,
> 
> Currently, I have a problem with linking to dynlib outside a bundle.
> Let me explain: We have a toolset that contains both unix-tools
> (applications without the .app suffix)
> and bundles (applications that have the .app suffix). After
> installation, tools are installed in "./bin"
> and shared libraries are installed in "./lib/mcrl2".
> 
> We set the following parameters, for linking:
> 
> set(CMAKE_SKIP_BUILD_RPATH false)
> set(CMAKE_BUILD_WITH_INSTALL_RPATH false)
> set(CMAKE_INSTALL_NAME_DIR "@executable_path/../lib/mcrl2")
> set(CMAKE_INSTALL_RPATH_USE_LINK_PATH true)
> 
> This allows for unix-tools to find the relatively located libraries at runtime.
> However, running a bundle causes a problem. It tries to find the
> libraries relative to the
> executable which is @executable_path/../lib/mcrl2/lib_XXX.dylib in the
> /Contents/MacOS,
> instead of the path relative to the bundle, which should be
> @executable_path/../../../lib/mcrl2/lib_XXX.dylib.
> 
> Perhaps, somebody has some pointers on how to tackle this problem.
> Any help is welcome.
> 
> Kind regards,
> Frank Stappers

Don't do anything special with your install_name, just use the defaults which uses absolute paths. Then, when you do a "make install", CMake will take care of changing the install_name's accordingly.

The only problem with this approach is when you want your Unix-tools and libraries to be "relocatable". In this case I would go with the relative install_name as you do above, but then use the BundleUtilities.cmake to copy the libraries into the .app bundles and fix up the install_name's appropriately.

HTH

Michael