On Tue, 22 Dec 2015, clin...@elemtech.com wrote:
On Dec 21, 2015 12:26 PM, Boudewijn Rempt <b...@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
--
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
