[CMake] still having rpath problems on osx

[Boudewijn Rempt]

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