Re: [CMake] still having rpath problems on osxZ
- On Dec 31, 2015, at 1:41 AM, Boudewijn Rempt b...@valdyas.org wrote: > I think I've finally figured out why I didn't get the results the cmake > documentation suggested I should be getting... It's the extra-cmake-modules > that I use, Krita being a KDE application. With these settings: > > set(KDE_SKIP_RPATH_SETTINGS 1) > set(CMAKE_MACOSX_RPATH 1) > set(BUILD_WITH_INSTALL_RPATH 1) > > My libraries are built with an @rpath id, instead of an absolute path id. Now > only the executable needs to have its rpath set correctly after install and > after making a bundle, and all libraries are found and all plugins find the > libraries, too. > > Without KDE_SKIP_RPATH_SETTINGS, everything gets set to full, absolute paths > on > doing a make install. That might make sense on Linux, I guess... But no wonder > that I was confused all the time. > > So, to check that I really understand it: > > On OSX, every library has an id. That id can be > /abs/o/lute/path/to/library.dylib or library.dylib or @rpath/library.dylib. Yes, there is an id. @executable_path and @loader_path are a couple other that can used in addition to the list you provided. > > The exectutable has a bunch of paths where it can look for libraries, and the > path + library.dylib has to match the library id. I'm not sure what you mean by that. The library id is used only at link time, and not at runtime. There is no matching to the library id at runtime. At link time, the id is taken as-is and put into the executable as a dependency. If you are familiar with SONAME on ELF platforms, think of the id in a dylib being similar. > > so, if the executable has > > @path = ../lib;../Frameworks > > and links to > > @path/library.dylib > > and a library with that id is in ../lib (or ../Frameworks) from the > executable's > location, everything will be fine. I think you have the idea there. But just in case, let me enumerate how the runtime loader looks at these: 1. an exectuable with a /absolute/path/to/library.dylib dependency The library is searched for at the absolute path. If not found, library.dylib is searched in /usr/local/lib:/lib:/usr/lib environment variables such as DYLD_LIBRARY_PATH can override search locations. 2. an executable with a library.dylib dependency library.dylib is searched in /usr/local/lib:/lib:/usr/lib environment variables such as DYLD_LIBRARY_PATH can override search locations. 3. a binary with a @executable_path/library.dylib dependency The library is located in the same directory as the executable If the binary is another shared library, whether in another directory or not, library.dylib will be searched for in the same directory as the executable. If not found, a search is made in /usr/local/lib:/lib:/usr/lib environment variables such as DYLD_LIBRARY_PATH can override search locations. both exectuables and libraries can have @executable_path 3. a binary with @loader_path/library.dylib dependency the library is located in the same directory as the binary (may be the same directory as the executable or not). If not found, a search is made in /usr/local/lib:/lib:/usr/lib environment variables such as DYLD_LIBRARY_PATH can override search locations. 4. a binary with @rpath/library.dylib dependency the binary can also have a list of rpaths embedded. Each rpath is used to replace the "@rpath" portion of the dependency to locate the dependency. For flexibility, rpaths may contain absolute paths, @executable_path or @loader_path. For example, a binary can have an rpath @loader_path/../lib, and a dependency @rpath/library.dylib. After substitution, you have: @loader_path/../lib/library.dylib. With that, go see how @loader_path is handled. If not found, a search is made in /usr/local/lib:/lib:/usr/lib environment variables such as DYLD_LIBRARY_PATH can override search locations. > > Which makes it easiest for me, I guess to have @rpath in the id for every > library, and on make install set the exectables' rpath to where I install the > libraries to, and on creating the bundle update the rpaths in the executable > to > the Frameworks folder. The only thing that won't work is running unittests > without installing, but that's not a big problem, for me... > I also find @rpath easiest for me. I make sure all my 3rd party non-system dependencies use @rpath. In my case, these libraries are built once and shared among multiple developers. Using @rpath also allows multiple developers to place these libraries in their own home directories, and CMake's automatic rpath handling helps simplify things. Then when I build my bundles or create packages, I don't need to do any "install_name_tool -change" work. I do set the rpaths on exectuables during install, which is nearly identical to what I do on Linux. I'm curious why the unit tests do not work. Mine work just fine for me. If you have a setting to skip rpaths in the build tree, I guess th
Re: [CMake] How to include config.h.in in VS project
Hi,
You must add those sources to add_executable/add_library as well.
Wish you a happy new year.
Best regards
Roman
> Am 29.12.2015 um 09:53 schrieb Mauro Ziliani :
>
> Hi all.
> I'm using CMake 3.4.1 for my projects.
> I'm working with Visual studio 10 2010 express and wxFormBuilder
> I'd like to include config.h.in and the wxFormBuilder projects (which has
> .fbp extension) in source_group.
>
> In CMakeLists.txt i put
>
> ...
>
> source_group("FormBiulder FBP" FILES main.fbp)
> source_group("Config IN" FILES config.h.in)
>
> But when I generate the final solution for visual studio the tree project has
> not the group I define.
>
> It seems the problem is the extestion .fbp or .in. that Cmake ignores
>
> How can I include .in e .fbp extensions has wel-known extension to put in the
> vcxproject list?
>
> Best regards,
>Mauro
> --
>
> 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
--
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
Re: [CMake] Cannot set FOLDER property to an interface (header-only) target
On 31.12.2015 14:19, David Cole via CMake wrote: I can't think of a reason why we would not whitelist the FOLDER property... Unless somebody else chimes in with one, perhaps you could submit a proposed patch to whitelist it? As far as I remember INTERFACE libraries don't generate visual studio projects. Without generated projects there is nothing to be organized by the FOLDER property. Nils -- 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
Re: [CMake] Cannot set FOLDER property to an interface (header-only) target
I can't think of a reason why we would not whitelist the FOLDER property... Unless somebody else chimes in with one, perhaps you could submit a proposed patch to whitelist it? D On Wednesday, December 30, 2015, Klaim - Joël Lamotte wrote: > The following CMake script: > > cmake_minimum_required(VERSION 3.4) > > add_library( mylib INTERFACE ) > set_property( TARGET mylib PROPERTY FOLDER /some/dir ) > > > Will trigger this error on configuration: > > CMake Error at CMakeLists.txt:4 (set_property): > INTERFACE_LIBRARY targets may only have whitelisted properties. The > property "FOLDER" is not allowed. > > > This prevent any interface library to be organized in Visual Studio > virtual folders. > Unfortunately it also mean that header-only targets can't be organized. > > I have no idea how this should be solved. Should the property just be > white-listed? > Or should a better have a another specific library mode for header-only > targets? > > Is there any workaround? > > Joël Lamotte > > -- 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
Re: [CMake] still having rpath problems on osxZ
Oh, and for reference, it's this code block:
# RPATH handling ##
if(NOT KDE_SKIP_RPATH_SETTINGS)
# Set the default RPATH to point to useful locations, namely where the
# libraries will be installed and the linker search path
if(NOT LIB_INSTALL_DIR)
message(FATAL_ERROR "LIB_INSTALL_DIR not set. This is necessary for using the
RPATH settings.")
endif()
set(_abs_LIB_INSTALL_DIR "${LIB_INSTALL_DIR}")
if (NOT IS_ABSOLUTE "${_abs_LIB_INSTALL_DIR}")
set(_abs_LIB_INSTALL_DIR "${CMAKE_INSTALL_PREFIX}/${LIB_INSTALL_DIR}")
endif()
if (UNIX)
# for mac os: add install name dir in addition
# check: is the rpath stuff below really required on mac os? at least it
seems so to use a stock qt from qt.io
if (APPLE)
set(CMAKE_INSTALL_NAME_DIR ${_abs_LIB_INSTALL_DIR})
endif ()
# add our LIB_INSTALL_DIR to the RPATH (but only when it is not one of
# the standard system link directories - such as /usr/lib on UNIX)
list(FIND CMAKE_PLATFORM_IMPLICIT_LINK_DIRECTORIES
"${_abs_LIB_INSTALL_DIR}" _isSystemLibDir)
list(FIND CMAKE_CXX_IMPLICIT_LINK_DIRECTORIES
"${_abs_LIB_INSTALL_DIR}" _isSystemCxxLibDir)
list(FIND CMAKE_C_IMPLICIT_LINK_DIRECTORIES
"${_abs_LIB_INSTALL_DIR}" _isSystemCLibDir)
if("${_isSystemLibDir}" STREQUAL "-1" AND "${_isSystemCxxLibDir}" STREQUAL "-1" AND
"${_isSystemCLibDir}" STREQUAL "-1")
set(CMAKE_INSTALL_RPATH "${_abs_LIB_INSTALL_DIR}")
endif()
# Append directories in the linker search path (but outside the project)
set(CMAKE_INSTALL_RPATH_USE_LINK_PATH TRUE)
endif (UNIX)
endif()
--
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
Re: [CMake] still having rpath problems on osxZ
I think I've finally figured out why I didn't get the results the cmake documentation suggested I should be getting... It's the extra-cmake-modules that I use, Krita being a KDE application. With these settings: set(KDE_SKIP_RPATH_SETTINGS 1) set(CMAKE_MACOSX_RPATH 1) set(BUILD_WITH_INSTALL_RPATH 1) My libraries are built with an @rpath id, instead of an absolute path id. Now only the executable needs to have its rpath set correctly after install and after making a bundle, and all libraries are found and all plugins find the libraries, too. Without KDE_SKIP_RPATH_SETTINGS, everything gets set to full, absolute paths on doing a make install. That might make sense on Linux, I guess... But no wonder that I was confused all the time. So, to check that I really understand it: On OSX, every library has an id. That id can be /abs/o/lute/path/to/library.dylib or library.dylib or @rpath/library.dylib. The exectutable has a bunch of paths where it can look for libraries, and the path + library.dylib has to match the library id. so, if the executable has @path = ../lib;../Frameworks and links to @path/library.dylib and a library with that id is in ../lib (or ../Frameworks) from the executable's location, everything will be fine. Which makes it easiest for me, I guess to have @rpath in the id for every library, and on make install set the exectables' rpath to where I install the libraries to, and on creating the bundle update the rpaths in the executable to the Frameworks folder. The only thing that won't work is running unittests without installing, but that's not a big problem, for me... -- 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
