CMP0068 CMake warning on mac

[hughbe]

Description

hugh@Hughs-MacBook-Air ~ % cmake --version
cmake version 3.17.3

CMake suite maintained and supported by Kitware (kitware.com/cmake).

hugh@Hughs-MacBook-Air runtime % ./build.sh -subset clr
  CMake Warning (dev):
    Policy CMP0068 is not set: RPATH settings on macOS do not affect
    install_name.  Run "cmake --help-policy CMP0068" for policy details.  Use
    the cmake_policy command to set the policy and suppress this warning.
  
    For compatibility with older versions of CMake, the install_name fields for
    the following targets are still affected by RPATH settings:
  
     mscordbi
  
  This warning is for project developers.  Use -Wno-dev to suppress it.

[Dotnet-GitSync-Bot]

I couldn't figure out the best area label to add to this issue. If you have write-permissions please help me learn by adding exactly one area label.

[ghost]

Tagging subscribers to this area: @ViktorHofer
See info in area-owners.md if you want to be subscribed.

[danmoseley]

@mikem8361

[trylek]

@mikem8361 - is it safe to remove the "Untriaged" label from this issue or do we need to track this item in the infra backlog reviews for .NET 5?

[mikem8361]

@janvorli do you know if on MacOS x64 that we really need the mscordbi's RPATH in CMakeLists.txt? Removing the below two lines gets rid of the warning, but will it break anything? mscordac/coreclr modules on MacOS don't seem to have RPATHs.

--- a/src/coreclr/dlls/mscordbi/CMakeLists.txt
+++ b/src/coreclr/dlls/mscordbi/CMakeLists.txt
@@ -6,9 +6,6 @@ if(CORECLR_SET_RPATH)
     if(CLR_CMAKE_HOST_ARCH_ARM64)
       set(CMAKE_BUILD_WITH_INSTALL_NAME_DIR ON)
       set(CMAKE_INSTALL_NAME_DIR "@rpath")
-    else(CLR_CMAKE_HOST_ARCH_ARM64)
-      set(CMAKE_BUILD_WITH_INSTALL_RPATH TRUE)
-      set(CMAKE_INSTALL_RPATH "@loader_path")
     endif(CLR_CMAKE_HOST_ARCH_ARM64)
   else()
     set(CMAKE_BUILD_WITH_INSTALL_RPATH TRUE)

/cc: @sdmaclea

[sdmaclea]

See #51751.

You will probably find create dump will not find the dbi w/o it. I am adding similar lines to fix a broken PAL test on macOS.

[mikem8361]

Createdump only loads the DAC not DBI, but it sounds like removing RPATH make cause some problems loading in some of case.

[mikem8361]

@janvorli, @sdmaclea, does anybody know why we use @rpath on OSX arm64 and @loader_path on x64? When I use @rpath for all OSX architectures it builds without warnings, the dotnet-diagnostictests and SOS can load DBI just fine.

6,12c6,7
<     if(CLR_CMAKE_HOST_ARCH_ARM64)
<       set(CMAKE_BUILD_WITH_INSTALL_NAME_DIR ON)
<       set(CMAKE_INSTALL_NAME_DIR "@rpath")
<     else(CLR_CMAKE_HOST_ARCH_ARM64)
<       set(CMAKE_BUILD_WITH_INSTALL_RPATH TRUE)
<       set(CMAKE_INSTALL_RPATH "@loader_path")
<     endif(CLR_CMAKE_HOST_ARCH_ARM64)
---
>     set(CMAKE_BUILD_WITH_INSTALL_NAME_DIR ON)
>     set(CMAKE_INSTALL_NAME_DIR "@rpath")

/cc: @hoyosjs

[sdmaclea]

I don't. @jkoritzinsky do you know?

[jkoritzinsky]

@janvorli is the best contact for this.

[janvorli]

The difference between @loader_path and @rpath is that @loader_path is always relative to the library or exe that loaded the library with @loader_path. The @rpath causes the linker to search a list of paths passed during linking via the -rpath option (and that can contain the @loader_path too). So it kind of adds one level of indirection.
The @rpath is in general needed when you want to have a library that can be e.g. embedded in another product or installed in a system wide location and the code using the library needs to be the one to decide the final location. In that case the @loader_path cannot express it. See https://www.mikeash.com/pyblog/friday-qa-2009-11-06-linking-and-install-names.html for a nice detailed explanation.
I don't see a reason why we should differ between arm64 and x64 and I would use @rpath on both.

[mikem8361]

I can't figure out how to get rid of this CMP0068 policy warning without possibly breaking something like managed debugging or SOS. @k15tfu recently switched back from "@rpath" to "@loader_path" for OSX. We could continue to ignore the policy warning but eventually it come back and bite us.

``RPATH`` settings on macOS do not affect ``install_name``.

CMake 3.9 and newer remove any effect the following settings may have on the
``install_name`` of a target on macOS:

* ``BUILD_WITH_INSTALL_RPATH`` target property
* ``SKIP_BUILD_RPATH`` target property
* ``CMAKE_SKIP_RPATH`` variable
* ``CMAKE_SKIP_INSTALL_RPATH`` variable

Previously, setting ``BUILD_WITH_INSTALL_RPATH`` had the effect of
setting both the ``install_name`` of a target to ``INSTALL_NAME_DIR``
and the ``RPATH`` to ``INSTALL_RPATH``.  In CMake 3.9, it only affects
setting of ``RPATH``.  However, if one wants ``INSTALL_NAME_DIR`` to
apply to the target in the build tree, one may set
``BUILD_WITH_INSTALL_NAME_DIR``.

If ``SKIP_BUILD_RPATH``, ``CMAKE_SKIP_RPATH`` or
``CMAKE_SKIP_INSTALL_RPATH`` were used to strip the directory portion
of the ``install_name`` of a target, one may set ``INSTALL_NAME_DIR=""``
instead.

The ``OLD`` behavior of this policy is to use the ``RPATH`` settings for
``install_name`` on macOS.  The ``NEW`` behavior of this policy is to ignore
the ``RPATH`` settings for ``install_name`` on macOS.

This policy was introduced in CMake version 3.9.  CMake version
3.20.2 warns when the policy is not set and uses ``OLD`` behavior.
Use the ``cmake_policy()`` command to set it to ``OLD`` or ``NEW``
explicitly.

.. note::
  The ``OLD`` behavior of a policy is
  ``deprecated by definition``
  and may be removed in a future version of CMake.

[sdmaclea]

Maybe setting INSTALL_NAME_DIR="@rpath" will give the same behavior?

[mikem8361]

Fix in PR: #68095