[MacPorts] #63261: cmake @3.20.5_1: rpath error when linking any project on 10.4

[MacPorts]

#63261: cmake @3.20.5_1: rpath error when linking any project on 10.4
-------------------------+-----------------------
  Reporter:  evanmiller  |      Owner:  michaelld
      Type:  defect      |     Status:  assigned
  Priority:  Normal      |  Milestone:
 Component:  ports       |    Version:  2.7.1
Resolution:              |   Keywords:  tiger
      Port:  cmake       |
-------------------------+-----------------------

Comment (by kencu):

 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.

-- 
Ticket URL: <https://trac.macports.org/ticket/63261#comment:8>
MacPorts <https://www.macports.org/>
Ports system for macOS