On Dec 21, 2015 12:26 PM, Boudewijn Rempt <b...@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 -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake
