macos cmake build install_name missing @rpath or abspath

[Chrismarsh]

When building openblas with cmake, I am seeing that the dylib on macos only has the dylib name as its install_name. Therefore, linking applications struggle to use this binary.

$ otool -D libopenblas.0.3.dylib
libopenblas.0.3.dylib:
libopenblas.0.dylib

Makefile built seems fine, likely by design.

I am wondering if this is an expected behaviour?

[martin-frbg]

The cmake build was a later addition and may still be missing some details of the gmake one. I take it the toplevel CMakeLists.txt is currently lacking the -headerpad_max_install-names -install_name ... options at or near line 274 ?

[Chrismarsh]

CMake can take of it. One just needs to add something like

IF(APPLE)
  SET(CMAKE_INSTALL_NAME_DIR @rpath)
ENDIF(APPLE)

https://cmake.org/cmake/help/latest/variable/CMAKE_INSTALL_NAME_DIR.html

edit: Actually, I think setting MACOSX_RPATH should be sufficient.
https://cmake.org/cmake/help/latest/prop_tgt/MACOSX_RPATH.html

[haampie]

@martin-frbg to me it makes more sense to bump the minimum cmake version to 3 (maybe 3.5?) so you get MACOSX_RPATH by default. See #4848.

Notice that CMake 3.19 already complains about OpenBLAS's cmake minimum version being too old.

Also notice that CMake 3 was released over a decade ago.

Changed in version 3.27: Compatibility with versions of CMake older than 3.5 is deprecated. Calls to cmake_minimum_required(VERSION) or cmake_policy(VERSION) that do not specify at least 3.5 as their policy version (optionally via ...<max>) will produce a deprecation warning in CMake 3.27 and above.

Changed in version 3.19: Compatibility with versions of CMake older than 2.8.12 is deprecated. Calls to cmake_minimum_required(VERSION) or cmake_policy(VERSION) that do not specify at least 2.8.12 as their policy version (optionally via ...<max>) will produce a deprecation warning in CMake 3.19 and above.

Otherwise the "better" fix would have been

cmake_policy(SET CMP0042 NEW)