[CMake] still having rpath problems on osx

[clinton at elemtech.com]

On Dec 21, 2015 12:26 PM, Boudewijn Rempt <boud at valdyas.org> wrote:
>
> I'm still having rpath problems when creating libraries on OSX... And I'm not sure what's going on here. Here's the output for a single library: 
>
> otool -L ../i/lib/libkritaimage.dylib 
> ../i/lib/libkritaimage.dylib: 
>      /Users/boud/dev/i/lib/libkritaimage.15.dylib (compatibility version 15.0.0, current version 15.0.0) 
>      /Users/boud/dev/i/lib/libkritawidgets.15.dylib (compatibility version 15.0.0, current version 15.0.0) 
>      /Users/boud/dev/i/lib/libkritapsd.15.dylib (compatibility version 15.0.0, current version 15.0.0) 
>      libboost_system.dylib (compatibility version 0.0.0, current version 0.0.0) 
>      @rpath/libImath.12.dylib (compatibility version 12.0.0, current version 12.0.0) 
>      @rpath/libIlmImf.22.dylib (compatibility version 22.0.0, current version 22.0.0) 
>      @rpath/libIex.12.dylib (compatibility version 12.0.0, current version 12.0.0) 
>      @rpath/libHalf.12.dylib (compatibility version 12.0.0, current version 12.0.0) 
>      @rpath/libIlmThread.12.dylib (compatibility version 12.0.0, current version 12.0.0) 
>      /Users/boud/dev/i/lib/libfftw3.3.dylib (compatibility version 8.0.0, current version 8.4.0) 
>      @rpath/libgsl.dylib (compatibility version 0.0.0, current version 0.0.0) 
>      /Users/boud/dev/i/lib/libkritaflake.15.dylib (compatibility version 15.0.0, current version 15.0.0) 
>      /Users/boud/dev/i/lib/libkritaodf.15.dylib (compatibility version 15.0.0, current version 15.0.0) 
>      /Users/boud/dev/i/lib/libkritaversion.15.dylib (compatibility version 15.0.0, current version 15.0.0) 
>      /Users/boud/dev/i/lib/libkritastore.15.dylib (compatibility version 15.0.0, current version 15.0.0) 
>      /Users/boud/dev/i/lib/libKF5Archive.5.dylib (compatibility version 5.0.0, current version 5.17.0) 
>      /Users/boud/dev/i/lib/libkritaundo2.15.dylib (compatibility version 15.0.0, current version 15.0.0) 
>      /Users/boud/dev/i/lib/libkritawidgetutils.15.dylib (compatibility version 15.0.0, current version 15.0.0) 
>      /Users/boud/dev/i/lib/libKF5ItemViews.5.dylib (compatibility version 5.0.0, current version 5.17.0) 
>      @rpath/QtPrintSupport.framework/Versions/5/QtPrintSupport (compatibility version 5.6.0, current version 5.6.0) 
>      /Users/boud/dev/i/lib/libKF5GuiAddons.5.dylib (compatibility version 5.0.0, current version 5.17.0) 
>      /Users/boud/dev/i/lib/libKF5Completion.5.dylib (compatibility version 5.0.0, current version 5.17.0) 
>      /Users/boud/dev/i/lib/libKF5ConfigGui.5.dylib (compatibility version 5.0.0, current version 5.17.0) 
>      /Users/boud/dev/i/lib/libKF5WidgetsAddons.5.dylib (compatibility version 5.0.0, current version 5.17.0) 
>      /Users/boud/dev/i/lib/libkritaglobal.15.dylib (compatibility version 15.0.0, current version 15.0.0) 
>      @rpath/QtConcurrent.framework/Versions/5/QtConcurrent (compatibility version 5.6.0, current version 5.6.0) 
>      @rpath/QtWidgets.framework/Versions/5/QtWidgets (compatibility version 5.6.0, current version 5.6.0) 
>      /Users/boud/dev/i/lib/libkritapigment.15.dylib (compatibility version 15.0.0, current version 15.0.0) 
>      @rpath/QtGui.framework/Versions/5/QtGui (compatibility version 5.6.0, current version 5.6.0) 
>      @rpath/QtXml.framework/Versions/5/QtXml (compatibility version 5.6.0, current version 5.6.0) 
>      /Users/boud/dev/i/lib/libkritaplugin.15.dylib (compatibility version 15.0.0, current version 15.0.0) 
>      /Users/boud/dev/i/lib/libKF5CoreAddons.5.dylib (compatibility version 5.0.0, current version 5.17.0) 
>      /Users/boud/dev/i/lib/libKF5ConfigCore.5.dylib (compatibility version 5.0.0, current version 5.17.0) 
>      /Users/boud/dev/i/lib/libKF5I18n.5.dylib (compatibility version 5.0.0, current version 5.17.0) 
>      @rpath/QtCore.framework/Versions/5/QtCore (compatibility version 5.6.0, current version 5.6.0) 
>      /usr/lib/libc++.1.dylib (compatibility version 1.0.0, current version 120.1.0) 
>      /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1225.1.1) 
>
> 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"

>
> Obviously, 
>       libboost_system.dylib (compatibility version 0.0.0, current version 0.0.0) 
> is wrong -- it's got neither an @rpath, nor a full path. 

If it is wrong, you need to fix it in boost, or fix it with install_name_tool before linking against it.

>
> I'm not sure even why some libraries are linked to with @rpath and others with a 
> full path after running a make install, but I cannot figure out why libboost_system 
> doesn't have anything. 

Because each of those dependent libraries indicate how they want to be found.

>
> libkritaimage is build with these settings: 
>
> * CMake is version 3.4.0 
>
> * Policy CMP0042 is set to NEW 
>
> * in the toplevel cmakelists.txt, there's 
>
> if (APPLE) 
>      set(CMAKE_MACOSX_RPATH ON) 
>      SET(CMAKE_SKIP_BUILD_RPATH TRUE) 
>      SET(CMAKE_BUILD_WITH_INSTALL_RPATH TRUE) 
>      SET(CMAKE_INSTALL_RPATH_USE_LINK_PATH TRUE) 
> endif () 
>
> I'm feeling dense, but I just cannot make out the documentation for these variables... CMAKE_INSTALL_RPATH_USE_LINK_PATH sounds like it should change the rpath on doing making install, but apparently that doesn't happen. 

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.


> But it results in: 
>
> otool -l libkritaimage.dylib 
>
> Load command 48 
>            cmd LC_RPATH 
>        cmdsize 48 
>           path @loader_path/../../../../lib (offset 12) 
> Load command 49 
>            cmd LC_RPATH 
>        cmdsize 32 
>           path @loader_path/../lib (offset 12) 
> Load command 50 
>            cmd LC_RPATH 
>        cmdsize 40 
>           path @loader_path/../Frameworks (offset 12) 
> Load command 51 
>            cmd LC_RPATH 
>        cmdsize 40 
>           path @executable_path/../lib (offset 12) 
> Load command 52 
>            cmd LC_RPATH 
>        cmdsize 48 
>           path @executable_path/../Frameworks (offset 12) 
>
> and since everything gets installed to lib, the secodn LC_RPATH points to the place where the library is really installed. 
>
> So I have to manually do 
>
> install_name_tool -change /Users/boud/dev/i/lib/libboost_system.dylib @rpath/libboost_system.dylib libkritaimage.dylib 
>
> to make the libkritaimage finr libboost_system -- and that just cannot be right... 

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.

Clint