cmake @3.20.5_1: rpath error when linking any project on 10.4

[evanmiller (Evan Miller)]

The ​CMake 3.20.1 notes indicate:

The -rpath linker flag is now specified as supported on all Apple platforms, not just macOS. The install_name_dir used for iOS, tvOS and watchOS should now default to @rpath instead of using a full absolute path and failing at runtime when the library or framework is embedded in an application bundle (see XCODE_EMBED_<type>).

Unfortunately -rpath is not supported on 10.4, and so linking any project using CMake 3.20.5 fails with an error such as:

:info:build [ 86%] Linking CXX executable fish_key_reader
:info:build /opt/local/bin/cmake -E cmake_link_script CMakeFiles/fish_key_reader.dir/link.txt --verbose=ON
:info:build /opt/local/bin/g++-mp-7 -pipe -Os -D__DARWIN_UNIX03 -DNDEBUG -I/opt/local/include -I/opt/local/include/LegacySupport -D_GLIBCXX_USE_CXX11_ABI=0 -Wall -Wextra -Wno-comment -Wno-address  -arch ppc -mmacosx-version-min=10.4 -Wl,-search_paths_first -Wl,-headerpad_max_install_names -L/opt/local/lib -Wl,-headerpad_max_install_names -lMacportsLegacySupport CMakeFiles/fish_key_reader.dir/src/fish_key_reader.cpp.o CMakeFiles/fish_key_reader.dir/src/print_help.cpp.o -o fish_key_reader  -Wl,-rpath,/opt/local/lib libfishlib.a /opt/local/lib/libcurses.dylib /opt/local/lib/libpcre2-32.dylib /opt/local/lib/libintl.dylib -latomic
:info:build ld: -rpath can only be used when targeting Mac OS X 10.5 or later
:info:build collect2: error: ld returned 1 exit status

Reverting to @3.19.8_0 fixes the issue on my system.

[kencu (Ken)]

this was expected.

We will likely want to continue to default to absolute paths on MacPorts on all systems for a number of reasons, so hopefully we will change this across the board for all cmake builds, not just Tiger.

I hope not too much stuff has been made with @rpaths, if any, or we'll have to revbump a ton of things...

[ryandesign (Ryan Carsten Schmidt)]

Aha! This explains why I've been having such trouble building anything on Tiger.

[kencu (Ken)]

I thought I held cmake back on Tiger...I did with libuv.

If not, we should hold it back to I guess 3.19.x until this gets sorted.

Very little software needs 3.20+ at present.

[evanmiller (Evan Miller)]

I have opened an issue upstream about it: ​https://gitlab.kitware.com/cmake/cmake/-/issues/22490

The offending pull request is here: ​https://gitlab.kitware.com/cmake/cmake/-/merge_requests/5980

It looks like the issue can be fixed with a 3-line patch.

[kencu (Ken)]

What is happening on current systems with cmake 20+ now? Is it using @rpaths as the PR suggests?

If so, we probably want to change it back to using full paths again for all systems on MacPorts, and rebuild anything that has been built with an @rpath link in it.

[evanmiller (Evan Miller)]

I believe the issue has to do with setting the default rpaths (defined by -rpath) rather than specific linkages with @rpath in them.

[kencu (Ken)]

That is what needs to be sorted out. Be pretty silly to set a default rpath (to what??) and then not use it, but crazier things have been done.

Time to break out otool and see what is really going on before more conjecture it seems.

[kencu (Ken)]

It appears that you are exactly right, Evan. Even though nothing is using @rpath linkage references, every library and every executable has an embedded reference to an added rpath added by this:

-Wl,-rpath,/opt/local/lib

where that path is defined by this, I presume:

-DCMAKE_INSTALL_RPATH="/opt/local/lib"

for example, minizip2's library:

$ otool -L /opt/local/lib/libminizip2.2.9.1.dylib
/opt/local/lib/libminizip2.2.9.1.dylib:
	/opt/local/lib/libminizip2.2.5.dylib (compatibility version 2.5.0, current version 2.9.1)
	/opt/local/lib/libz.1.dylib (compatibility version 1.0.0, current version 1.2.11)
	/opt/local/lib/libbz2.1.0.dylib (compatibility version 1.0.0, current version 1.0.8)
	/opt/local/lib/libiconv.2.dylib (compatibility version 9.0.0, current version 9.1.0)
	/System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation (compatibility version 150.0.0, current version 1455.255.0)
	/System/Library/Frameworks/Security.framework/Versions/A/Security (compatibility version 1.0.0, current version 58286.70.19)
	/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1252.50.4)

$ otool -l /opt/local/lib/libminizip2.2.9.1.dylib | grep LC_RPATH -A2 -B2
compatibility version 1.0.0
Load command 16
          cmd LC_RPATH
      cmdsize 32
         path /opt/local/lib (offset 12)

and

$ otool -L /opt/local/bin/minigzip
/opt/local/bin/minigzip:
	/opt/local/lib/libminizip2.2.5.dylib (compatibility version 2.5.0, current version 2.9.1)
	/opt/local/lib/libz.1.dylib (compatibility version 1.0.0, current version 1.2.11)
	/opt/local/lib/libbz2.1.0.dylib (compatibility version 1.0.0, current version 1.0.8)
	/opt/local/lib/libiconv.2.dylib (compatibility version 9.0.0, current version 9.1.0)
	/System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation (compatibility version 150.0.0, current version 1455.255.0)
	/System/Library/Frameworks/Security.framework/Versions/A/Security (compatibility version 1.0.0, current version 58286.70.19)
	/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1252.50.4)

$ otool -l /opt/local/bin/minigzip | grep LC_RPATH -A2 -B2
compatibility version 1.0.0
Load command 19
          cmd LC_RPATH
      cmdsize 32
         path /opt/local/lib (offset 12)

I'm not exactly sure when cmake started adding this LC_RPATH to every build; I installed an older version of minizip2 from the binary archives, and it has the added LC_RPATH too.

So is the change here that they just started trying to add this on Tiger too? Or some other nuance I didn't come across yet?

At least it appears that what cmake is building now is OK -- no @rpath references directly, at least -- on Leopard+.

Perhaps it will just be a simple patch then, to make it stop doing this on Tiger. That would be nice, if it is that simple.

[kencu (Ken)]

Yes, only Tiger has changed, in the commit you noted <​https://gitlab.kitware.com/cmake/cmake/-/commit/4aed96e2309e64571aabfda263b3ca4c4f62d619>

In this file:

Modules/Platform/Darwin.cmake

set(CMAKE_SHARED_MODULE_SUFFIX ".so")
set(CMAKE_MODULE_EXISTS 1)
set(CMAKE_DL_LIBS "")
- 
- # Enable rpath support for 10.5 and greater where it is known to work.
- if("${DARWIN_MAJOR_VERSION}" GREATER 8)
-   set(CMAKE_SHARED_LIBRARY_RUNTIME_C_FLAG "-Wl,-rpath,")
- endif()
+ set(CMAKE_SHARED_LIBRARY_RUNTIME_C_FLAG "-Wl,-rpath,")

foreach(lang C CXX OBJC OBJCXX)
  set(CMAKE_${lang}_OSX_COMPATIBILITY_VERSION_FLAG "-compatibility_version ")

So it would seem that a simple patch that reverts that, and we are back in business on Tiger.

Luckily MacPorts has almost exclusively avoided using @rpath references, so we should be undamaged here.

[kencu (Ken)]

​https://github.com/macports/macports-ports/pull/11736

needs actual testing on Tiger, but looks to be sufficient to do the job.

[evanmiller (Evan Miller)]

Looks good to me. I'll badger them in the Gitlab issue to revert that commit. Its purpose appears to be purely aesthetic.

[mojca (Mojca Miklavec)]

Just to clarify. If you read the commit comments, that change was needed for the sake of proper functionality on iOS. So what's needed is basically a condition that only excludes this on Tiger, but not on iOS.

The condition if("${DARWIN_MAJOR_VERSION}" GREATER 8) probably returns false on iOS where DARWIN_MAJOR_VERSION is most likely not defined.

[evanmiller (Evan Miller)]

Yes, there is more context to the change than meets the eye – so it's not aesthetic. I am wondering if a change is possible that fixes iOS and restores 10.4 support.

[kencu (Ken)]

In 51496245e108d51ce8cdeb510fd1efef29430123/macports-ports (master):

cmake: restore no-default-rpath usage on Tiger

cmake is gradually removing support for Tiger
at present, only the default adding of an -rpath
to all library and executables is troublesome however

this reverts:
​https://gitlab.kitware.com/cmake/cmake/-/commit/4aed96e2309e64571aabfda263b3ca4c4f62d619

closes: #63261

[evanmiller (Evan Miller)]

Upstream merge request: ​https://gitlab.kitware.com/cmake/cmake/-/merge_requests/6426

[kencu (Ken)]

very good ... thanks for doing that.