Added a github build for MacOs/arm64 https://github.com/GrandOrgue/grandorgue/discussions/1153

[oleg68]

This PR adds building GrandOrgue for MacOs/arm64.

Unfortunally I cannot test it because I don't have an apple/M1 device. So if something doesn't work on M1/M2, it will be fixed in separate issues.

[willeke1234]

The app crashes because of Code signature invalid. Code signing is mandatory. The libs from HomeBrew are code signed but they are modified. Why are they modified?

[oleg68]

Code signing is mandatory

But how did GrandOrgue work on macos/x86_64 without code signing?

The libs from HomeBrew are code signed but they are modified

Which library is modified? Could you post here the full error message or a screenshot?

[willeke1234]

But how did GrandOrgue work on macos/x86_64 without code signing?

Code signing is mandatory on Macs with Apple silicon.

New in macOS 11 on Macs with Apple silicon, and starting in macOS Big Sur 11 beta 6, the operating system enforces that any executable must be signed before it’s allowed to run.

Source: macOS Big Sur 11.0.1 Universal Apps Release Notes:

Which library is modified? Could you post here the full error message or a screenshot?

All libraries are modified. The creation and modification dates are the changed and when I verify the code signature I get:

invalid signature (code or signature have been modified)

But I found the difference (paths). The following commands must be executed to code sign everything. I found Using cmake to sign target but in which script do I add what?

codesign --force -s - path_to_libs/*.*
codesign --force -s - path_to_app

Other questions:

What does the workaround in build-scripts/for-osx/prepare-osx.sh do? Is it still necessary? Does this affect other projects on my Mac?

In build-on-osx.sh: "-DCMAKE_OSX_DEPLOYMENT_TARGET=12.1" is this still necessary? Or was it added with the workaround for macOS 10.15?

[oleg68]

Support of Apple/arm64 appears to be a much more complex thing than I thought.

I created a separate issue for signing #1835.

[pgcrowe]

I’m so excited to see Apple ARM support in the works! I have an Apple M3 Max processor, and would be more than happy to test new builds on that architecture. Also, I have an Apple Developer account, and am happy to use that to sign, if needed.

I’m having trouble building GrandOrgue for ARM locally on my Mac (using CMake in Terminal). Does anyone have a script for this? I tried a number of tweaks, including adding set(CMAKE_OSX_ARCHITECTURES "arm64" CACHE INTERNAL "" FORCE) to CMakeLists.txt, which did force GrandOrgue to attempt to build for ARM. However, I get the following error when the compiler reaches the WxWidgets library: ld: symbol(s) not found for architecture arm64. Any suggestions?

[oleg68]

@pgcrowe

I’m having trouble building GrandOrgue for ARM locally on my Mac (using CMake in Terminal). Does anyone have a script for this?

https://github.com/GrandOrgue/grandorgue/blob/master/build-scripts/for-osx/prepare-osx.sh https://github.com/GrandOrgue/grandorgue/blob/master/build-scripts/for-osx/build-on-osx.sh

[pgcrowe]

Thanks @oleg68! Those were the same scripts that I had tried before. I've managed to trace my compiler issues to the PortAudio library, and a bug introduced with commit 877 on February 23rd. See: https://github.com/PortAudio/portaudio/commit/4600d814564c392ec848d4de9cb41e07aa9c16ba

After switching PortAudio to commit 878 (February 9, 2024), I was able to compile without issue. I'm not sure if the bug is caused by PortAudio, or how GrandOrgue handles PortAudio. But anyway... FYI!

[pgcrowe]

So far in my testing, all main functions appear to behave as normal on the ARM build. However, I did note a bug with the help window appearing to be empty (missing all contents of the manual).

[oleg68]

Thanks @oleg68! Those were the same scripts that I had tried before. I've managed to trace my compiler issues to the PortAudio library, and a bug introduced with commit 877 on February 23rd. See: PortAudio/portaudio@4600d81

But GrandOrgue source code refers to the PortAudio 19.7.0 without this bug. Could you try compile with the stock version?

[oleg68]

So far in my testing, all main functions appear to behave as normal on the ARM build.

Have you used the build scripts/cmake/make/cpack? If so, please give a recepy how have you signed the application together with using these automated tools there: https://github.com/GrandOrgue/grandorgue/issues/1835.

However, I did note a bug with the help window appearing to be empty (missing all contents of the manual).

Seems you have missed install some necessary dependencies. Have you run prepare-osx.sh ?

[willeke1234]

I did note a bug with the help window appearing to be empty (missing all contents of the manual).

HomeBrew installs in /usr/local on Intel and in /opt/homebrew on ARM. In build-on-osx.sh:

OS_PRMS="-DDOCBOOK_DIR=/usr/local/opt/docbook-xsl/docbook-xsl -DCMAKE_OSX_DEPLOYMENT_TARGET=12.1"

This path is /opt/homebrew/opt/docbook-xsl/docbook-xsl on ARM.

compiler issues to the PortAudio library

How did you get the GrandOrgue source code? See #1158

[willeke1234]

HomeBrew installs in /usr/local on Intel and in /opt/homebrew on ARM. The workaround in prepare-osx.sh does:

for F in $(grep -l '(, weak)\?' /usr/local/Cellar/cmake/*/share/cmake/Modules/GetPrerequisites.cmake); do

I assume the workaround doesn't work at the moment but the app appears to work.

[oleg68]

HomeBrew installs in /usr/local on Intel and in /opt/homebrew on ARM. The workaround in prepare-osx.sh does:

for F in $(grep -l '(, weak)\?' /usr/local/Cellar/cmake/*/share/cmake/Modules/GetPrerequisites.cmake); do

What is the full path to GetPrerequisites.cmake? You have to add it to this script

I assume the workaround doesn't work at the moment but the app appears to work.

It is important for building a .dmg bundle. Otherwise some libraries are not copied there.

[willeke1234]

What is the full path to GetPrerequisites.cmake?

/opt/homebrew/Cellar/cmake/3.28.3/share/cmake/Modules/GetPrerequisites.cmake

[oleg68]

What is the full path to GetPrerequisites.cmake?

/opt/homebrew/Cellar/cmake/3.28.3/share/cmake/Modules/GetPrerequisites.cmake

Then it should be replaced with

for F in $(grep -l '(, weak)\?'  {/usr/local,/opt/homebrew}/Cellar/cmake/*/share/cmake/Modules/GetPrerequisites.cmake); do

[willeke1234]

I assume it works, I now get:

grep: /usr/local/Cellar/cmake/*/share/cmake/Modules/GetPrerequisites.cmake: No such file or directory
Patching /opt/homebrew/Cellar/cmake/3.28.3/share/cmake/Modules/GetPrerequisites.cmake...

The libs in both ARM apps were and are the same. The Intel app from GitHub has some extra libs, I don't know if it's a problem. Differences:

Intel libcrypto.3.dylib libdb-18.1.dylib libssl.3.dylib libwavpack.1.2.5.dylib

ARM libdb-5.3.dylib libwavpack.1.dylib

[oleg68]

Intel libcrypto.3.dylib libdb-18.1.dylib libssl.3.dylib

GrandOrgue does not use them directly. May be they come by a transidive dependency.

[larspalo]

@oleg68 I've no access to a Mac to test anything, but if/when we have a working build for distribution here, I'll happily approve. I try to follow the discussion and feedback here.

[oleg68]

@larspalo I don't hope that we can achieve a working macos/osx build due #1835.

[MStraeten]

on macports the silicon version builds fine with deployment target 11.1 codesign --verify --verbose GrandOrgue.app returns GrandOrgue.app: code has no resources but signature indicates they must be present codesign --sign - --verbose --deep --force GrandOrgue.app gives a proper result if someone wants to check: GrandOrgue_3.14.0.zip

[vpoguru]

@MStraeten, fantastic! Seems to work with charm! Congrats!

[willeke1234]

@MStraeten the code signing topic is here: #1835

[oleg68]

Replaced with #1864