Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

CMake warnings under OS X: MACOSX_RPATH is not specified for the following targets

I try to build a CMake-based software under OS X (Yosemite) which can be built successfully under Fedora 21. It uses a bunch of libraries. Both, big open ones like Boost and some self-written ones lying in /installation_folder/lib. I use CMake version 3.3.0.

After executing

mkdir build
cd build
cmake .. -DCMAKE_C_COMPILER=/usr/local/Cellar/gcc/5.2.0/bin/gcc-5 -DCMAKE_CXX_COMPILER=/usr/local/Cellar/gcc/5.2.0/bin/g++-5  -DCMAKE_MODULE_PATH=${PWD}/../external/install/share/llvm/cmake 

I get the following warnings:

CMake Warning (dev):
Policy CMP0042 is not set: MACOSX_RPATH is enabled by default.  Run "cmake
--help-policy CMP0042" for policy details.  Use the cmake_policy command to
set the policy and suppress this warning.

MACOSX_RPATH is not specified for the following targets:

ClangWrapper
Structure
WCETXML

This warning is for project developers.  Use -Wno-dev to suppress it.

The CMakeLists.txt contains the following lines regarding RPATH:

SET(CMAKE_SKIP_BUILD_RPATH FALSE)
SET(CMAKE_INSTALL_RPATH "${CMAKE_INSTALL_PREFIX}/lib")
SET(CMAKE_INSTALL_RPATH_USE_LINK_PATH TRUE)

LIST(FIND CMAKE_PLATFORM_IMPLICIT_LINK_DIRECTORIES "${CMAKE_INSTALL_PREFIX}/lib" isSystemDir)

IF("${isSystemDir}" STREQUAL "-1")
  SET(CMAKE_INSTALL_RPATH "${CMAKE_INSTALL_PREFIX}/lib")
ENDIF("${isSystemDir}" STREQUAL "-1")

All I can say is that ${CMAKE_INSTALL_PREFIX}/lib is indeed the correct path, and that other libraries like Boost are found correctly.

Ignoring the warnings and continuing with "make" in the build directory results in a linking error.

I read the CMake Wiki RPATH handling article, but I am still not able to distinguish between these path variables and their correct use on OS X.

like image 756
fotinsky Avatar asked Jul 22 '15 11:07

fotinsky


3 Answers

Adding set(CMAKE_MACOSX_RPATH 1) into CMakeLists.txt, before the above written statements, lets the warnings disappear. The linking problem after executing make stays. This brings me to the assumption that my RPATH setup has nothing to do with my linking problem.

Nevertheless, this thread's problem is solved. An explanation about the correct use of the RPATH options inside CMakeLists.txt is still very welcome!

like image 182
fotinsky Avatar answered Nov 10 '22 17:11

fotinsky


Well, I'll just go one step forward from @fotinsky's answer. (Feel free to incorporate this into your answer.)

The output of the warning's suggestion to run cmake-policy --help-policy CMP0042 is:

CMake 2.8.12 and newer has support for using ``@rpath`` in a target's install
name.  This was enabled by setting the target property
``MACOSX_RPATH``.  The ``@rpath`` in an install name is a more
flexible and powerful mechanism than ``@executable_path`` or ``@loader_path``
for locating shared libraries.

CMake 3.0 and later prefer this property to be ON by default.  Projects
wanting ``@rpath`` in a target's install name may remove any setting of
the ``INSTALL_NAME_DIR`` and ``CMAKE_INSTALL_NAME_DIR``
variables.

This policy was introduced in CMake version 3.0.  CMake version
3.1.3 warns when the policy is not set and uses OLD behavior.  Use
the cmake_policy command to set it to OLD or NEW explicitly.

This simply means that in later cmake versions, the user is required to explicitly enable or disable CMAKE_MACOSX_RPATH.

There's also more background info on the introduction of this variable in this CMake blog entry.

like image 25
hopia Avatar answered Nov 10 '22 17:11

hopia


As mentioned in a comment above, if you don't need to target older versions of cmake, you can simply set:

cmake_minimum_required (VERSION 3.0)

This removes the ambiguity of default values between major versions and simply enables runtime path behaviors by default.

like image 3
indirectlylit Avatar answered Nov 10 '22 15:11

indirectlylit