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

Question

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.

Wellbeing

Our CMakeLists.txt was created while developing only on Linux. Maybe another option causes the warning. I am not sure. – Wellbeing

Don't use RPATH's. They will cause the resulting binary to fail a security audit. Instead, use -install_name and install_name_tool. – Calumnious

Answer 1

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!

Wellbeing

Did you ever solve the linking problem? I am having same trouble – Philipps

Yes, I solved it. The above mentioned RPATH variable has nothing to do with the linking problem. It was necessary to add some more libraries in the CMakeLists.txt which CMake could find automatically under Linux, but not under OS X. Update: Disabling (!) RPATH explicitly, like hopia mentioned, could also fix the problem. I have to try it out. – Wellbeing

or you can set cmake_minimum_required (VERSION 3.0) – Bearwood

Answer 2

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.

Hereunder

Very interesting. CMAKE_INSTALL_NAME_DIR is indeed used in our CMakeLists.txt. By not setting RPATH or by enabling RPATH, the INSTALL_NAME variables are maybe ignored. I will try out disabling RPATH explicitly. – Wellbeing

Answer 3

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.

False