There has been some discussion about the recent change Apple made for macOS 11.0beta7 for ARM Mac only (-not- Intel Mac at this time); we in MP-land had some on this PR < https://github.com/macports/macports-ports/pull/8328 >. As pointed out, a better venue for discussion would be these lists.
The brief summary is that Apple is instituting code signing for all binaries during linking as noted here < https://developer.apple.com/documentation/macos-release-notes/macos-big-sur-11-universal-apps-beta-release-notes#Updates-in-macOS-Big-Sur-11-Universal-Apps-Beta-7 >. The signing is as-hoc and done automatically; it is invalidated if one modifies the binary in any way ... for example using "strip", or "install_name_tool" to change the name of a required library, or even the self-ID name. Many MacPorts installs use various post-linking means to tweak the resulting binary, and hence these are not currently usable under macOS 11.0beta7 or more recent on ARM Mac only; again: this change is NOT for Intel Mac -- at least not at this time. One can test whether the signing is valid via the command: "codesign -v FILE" ; according to Apple one should use "codesign -v -vvvv --ignore-resources FILE" to be more verbose as well as look at just the non-resource binary. Both work in my testing. In my initial testing, some of the binaries can be made to work via the command "[sudo] codesign -s - --preserve-metadata=identifier,entitlements,flags,runtime -f FILE" ... but, not all! For example: {{{ % codesign -v -vvvv --ignore-resources /opt/local/Library/Frameworks/Python.framework/Versions/3.8/bin/python3.8 /opt/local/Library/Frameworks/Python.framework/Versions/3.8/bin/python3.8: invalid signature (code or signature have been modified) % sudo codesign -s - --preserve-metadata=identifier,entitlements,flags,runtime -f /opt/local/Library/Frameworks/Python.framework/Versions/3.8/bin/python3.8 /opt/local/Library/Frameworks/Python.framework/Versions/3.8/bin/python3.8: replacing existing signature /opt/local/Library/Frameworks/Python.framework/Versions/3.8/bin/python3.8: the codesign_allocate helper tool cannot be found or used % which codesign /usr/bin/codesign % which codesign_allocate /usr/bin/codesign_allocate }}} So in this case, "codesign_allocate" cannot be used for some non-obvious reason (as it clearly is in the PATH and works for some other codesign efforts). The same holds true for some of the Python libraries and some of the primary executables -- but, not all! Mentioned as possible fixes were: (1) inserting MP strip and install_name_tool wrappers that sign the binary if the signature is broken; or (2) a new step in destroot_finish . Let's pick up the discussion here, and try to work out a fix in short order. For those of us trying to do anything within MacPorts using ARM Mac, this new feature is causing significant issues & needs to be dealt with so that we can get back to real work instead of fighting macOS::codesign . Cheers! - MLD
