<div dir="auto">ah yes, your question was arm64-specific so that led to the gcc assumption.</div><div dir="auto"><br></div><div dir="auto">the way the cmake PG configures cmake breaks testing on all archs and systems.</div><div dir="auto"><br></div><div dir="auto">this comes up regularly, eg</div><div dir="auto"><br></div><div dir="auto"><div><a href="https://lists.macports.org/pipermail/macports-dev/2021-September/043754.html">https://lists.macports.org/pipermail/macports-dev/2021-September/043754.html</a></div><br></div><div dir="auto">Perhaps it might beneficially be changed.</div><div dir="auto"><br></div><div dir="auto">K</div><div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sun, May 29, 2022 at 22:17 Ryan Schmidt <<a href="mailto:ryandesign@macports.org">ryandesign@macports.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On May 24, 2022, at 10:22, Ken Cunningham wrote:<br>
> <br>
>> Does anyone know why things seem to be using rpath on arm64 builds<br>
> <br>
> Basically, it comes down to the fact that Apple has disallowed DYLD_LIBRARY_PATH to work on newer systems.<br>
<br>
> So gcc is installing it’s libraries with the @rpath linkage<br>
<br>
So you're talking about how SIP doesn't pass DYLD_LIBRARY_PATH to child processes on El Capitan and later, which breaks the gcc test suite, therefore gcc now uses @rpath at build time to fix the problem, and does not rewrite the install_names at install time, therefore things with @rpath get installed.<br>
<br>
That's not the issue that prompted me to start this thread.<br>
<br>
When I enabled the test suite for the portmidi port (which does not use gcc)...<br>
<br>
<a href="https://github.com/macports/macports-ports/commit/fd447d210e1814b1303c5013d088efa673470d77" rel="noreferrer" target="_blank">https://github.com/macports/macports-ports/commit/fd447d210e1814b1303c5013d088efa673470d77</a><br>
<br>
...I set "DYLD_LIBRARY_PATH=." in test.env so that the executable it runs can find the library it just built. This worked fine on Catalina x86_64 but on Big Sur arm64 it failed with the error message:<br>
<br>
dyld: Library not loaded: @rpath/libportmidi.2.dylib<br>
  Referenced from: /path/to/portmidi/work/build/./qtest<br>
  Reason: image not found<br>
<br>
Seeing "@rpath" in this error message, I added "-DCMAKE_BUILD_WITH_INSTALL_RPATH=OFF" to configure.args (to counteract "-DCMAKE_BUILD_WITH_INSTALL_RPATH=ON" set by the cmake portgroup) and the problem went away.<br>
<br>
Perhaps placing the blame on @rpath was the wrong conclusion, since I now realize that the install_names also use @rpath on Catalina x86_64 yet the test worked there. I just don't understand then why disabling @rpath on Big Sur arm64 made the tests work.<br>
<br>
It seemed to me like I was seeing a lot of @rpath-related issues especially on arm64 lately, and this latest instance with portmidi prompted me to ask about it, but it could be that most or all of the other instances were related to the gcc situation you already discussed. I know we are using a different branch of gcc for arm64 so maybe that explains why the @rpath-related changes you mentioned only appear on arm64 so far.<br>
<br>
</blockquote></div></div>