[MacPorts] #72287: simulavr @1.1.0: build failure when SIP is enabled (was: simulavr @1.1.0 build failure)

[MacPorts]

#72287: simulavr @1.1.0: build failure when SIP is enabled
---------------------------+--------------------
  Reporter:  weiminshen99  |      Owner:  (none)
      Type:  defect        |     Status:  new
  Priority:  Normal        |  Milestone:
 Component:  ports         |    Version:
Resolution:                |   Keywords:
      Port:  simulavr      |
---------------------------+--------------------

Comment (by ryandesign):

 It is likely that my workaround only works on machines where System
 Integrity Protection is disabled. The
 [https://ports.macports.org/port/simulavr/details/ port health indicators]
 show success on OS X 10.10 and earlier and failure on 10.11 and later. SIP
 was introduced in 10.11. At the time I was using a MacBook Pro with an
 unsupported newer macOS version installed using OpenCore Legacy Patcher so
 I didn't notice the problem. OCLP automatically disables parts of SIP as
 required to accomplish its goal of enabling the use of newer macOS. The
 port health indicators also show success on x86_64 macOS 13 and 14. At the
 time, our x86_64 macOS 13 and 14 build machine was also using OCLP. (Since
 then, we've upgraded to a new machine that doesn't require OCLP to run
 newer macOS.)

 When SIP is enabled, environment variables starting with `DYLD_` are not
 passed down to child processes; the solution is to set `DYLD_LIBRARY_PATH`
 on the executable that needs it (`simulavr`) not at a higher level (e.g.
 on `cmake` as I'm doing in my workaround).

 You don't see this when building outside MacPorts if you don't use all the
 cmake flags that MacPorts uses automatically via the cmake portgroup.
 Specifically the fact that [https://github.com/macports/macports-
 ports/blob/508eea12ca3fbe313a827ebe4bde64afdd5fffd3/_resources/port1.0/group/cmake-1.1.tcl#L105
 we use] `-DCMAKE_BUILD_WITH_INSTALL_RPATH:BOOL=ON` is probably responsible
 for the problem. This has tripped us up many times before. I wonder, as
 I'm sure I have wondered many many times before, why we are using that.

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