[CMake] still having rpath problems on osx

[Michael Jackson]

> On Dec 23, 2015, at 12:02 PM, Boudewijn Rempt <boud at valdyas.org> wrote:
> 
> On Tue, 22 Dec 2015, clinton at elemtech.com wrote:
> 
>> 
>> On Dec 21, 2015 12:26 PM, Boudewijn Rempt <boud at valdyas.org> wrote:
>>> 
>>> All libraries I link to are built. Some come with a cmake build system, some with an automake build system, boost with something else altogether... But I wouldn't have expected the way a library is built to make a difference for the link lines in the library that links to the other library. 
>> 
>> You may not expect this, but this is how it works.  @rpath is a way for a library to say, "i want to be found using rpaths"
>> 
> 
> Hm... Okay -- so, since I all my dependencies myself as cmake external projects, I guess I want all of them set to rpath. I guess that for boost, with its own build system, I'll need to add a separate fix-up step to my cmake externals project for boost. I have to check how I can fix the dependencies that are still automake/autoconf based. And I'll try what you suggest below for my own project.

I have written scripts to do things like that for boost and ITK where the libraries do not have anything like @rpath or the absolute path to the installed library. After installing I run those scripts to “fix” the libraries so when I debug I can just run the application. During packaging I then run CMake’s BundleUtilities to copy in the libraries and adjust the libraries to have @rpath or @executable_path.

When fixing up a library make sure you also fix all the dependent libraries that might be there. For things like Boost or ITK their higher level libraries depend on their lower level libraries. Using “otool -L” you can see this. Make sure you update EVERY path in the library.

Also using MacDeployQt will NOT fix up any NON-Qt libraries (like Boost, HDF5.. ) so you will still need to run/write something that fixes all of those libraries. For our project we wrote a pure CMake script that does everything we need to fix up our bundles so that everything is self contained.  

—
Mike Jackson

> 
>> I think you are trying to hard to fix the problem in your cmake, by setting too many variables.  The libraries you link against need fixed to behave how you want.
>> 
>> By setting
>> set(CMAKE_MACOSX_RPATH ON) you are setting @rpath for the install name of any library you build.
>> 
>> By setting INSTALL_RPATH, you are indicating directories to substitute @rpath at runtime.
>> 
>> 
>>> 
>>> * And for the library itself, I explicitly set: 
>>> if (APPLE)      set_target_properties(kritaimage PROPERTIES INSTALL_RPATH "@loader_path/../../../../lib;@loader_path/../lib;@loader_path/../Frameworks;@executable_path/../lib;@executable_path/../Frameworks") endif() 
>>> Though I sort of feel that it shouldn't be necessary to explicitly set an rpath to something I build.
>> 
>> 
>> If you are going to install the library, you should set INSTALL_RPATH.
>> 
> 
> Well, the way I set it up, which may be wrong of course, I install all the dependecies to ~/dev/i, then build the main application that uses those dependencies. When developing, I run the app bundle directly, linked to the dependencies in ~/dev/i/lib; when distributing, I use macdeployqt to populate the app bundle with all the dependencies and data.
> 
> 
>> 
>> It is partly right.  However, you may find it simpler to change the id of libraries before you link against them.
>> For example
>> install_name_tool -id @rpath/libboost_system.dylib libboost_system.dylib
>> 
>> And use "install_name_tool -change" for any libraries that link against the library with the changed id, but only if you change the id after linking.
>> 
> 
> Thanks! I think I'm finally beginning to grasp the idea :-)
> 
> 
> -- 
> Boudewijn Rempt | http://www.krita.org, http://www.valdyas.org-- 
>