Add darwin arm64 target #34
Conversation
This commit add support for the darwin arm64 target. Additionally provides: - Update Go to v1.16.0 - Update fyne cli to v2.0.1 - Add darwin arm64 target - Remove darwin 386 target Fixes fyne-io#33
|
This looks like a really great addition, thanks. |
There was a problem hiding this comment.
Just a few comments and ideas while I wait for the images to build:
- Would it be possible to have some sort of
fyne-cross build-darwin pathtoxcodecommand to avoid having to cd into the project root and runmakecommands? Just a thought to make darwin builds easier. I don't think there would be much use for doing this for the base images. - Would it be possible to just download the Command Line Tools instead? According to Apple, they contain all the SDK and headers needed either way. This means downloading 400 MB instead of 11 GB and make our lives a lot easier.
I think you are mis-reading the information there. the 400MB file does not contain all the SDKs, it enables their use on the commandline. Those tools require XCode (and the SDKs it includes) to be present first. |
Ah. I see now. It looks like you probably are correct. |
|
Perhaps some of the people from fyne-io/fyne#1922, like @zdima and @sirkon could try this out as they have M1 machines? If so, it would be greatly appreciated 🙂 |
|
@Jacalz my first understanding was the same of @andydotxyz but looking closer at the osxcross doc it seems that starting from Xcode command line tools 12.x it is known to work. Let's give it a try.
Sure, in the plan this was the next step. Before implement that just want to be sure the macOS cross toolchain and image work as expected ;-) |
There was a problem hiding this comment.
Compiling
Running cross-compilation for Darwin (amd64, arm64), Linux (amd64, arm64) and FreeBSD (amd64) all completed without issues. The darwin build felt a bit slower than before, I think, now not too slow by any means (excluding the image build time).
However, the windows build seemed to fail:
~/go/bin/fyne-cross windows -arch amd64 -app-id com.github.jacalz.wormhole-gui -icon internal/assets/icon/icon-512.png
[i] Target: windows/amd64
[i] Cleaning target directories...
[✓] "bin" dir cleaned: /home/jacob/go/src/github.com/Jacalz/wormhole-gui/fyne-cross/bin/windows-amd64
[✓] "dist" dir cleaned: /home/jacob/go/src/github.com/Jacalz/wormhole-gui/fyne-cross/dist/windows-amd64
[✓] "temp" dir cleaned: /home/jacob/go/src/github.com/Jacalz/wormhole-gui/fyne-cross/tmp/windows-amd64
[i] Checking for go.mod: /home/jacob/go/src/github.com/Jacalz/wormhole-gui/go.mod
[✓] go.mod found
Could not create windows resource exec: "x86_64-w64-mingw32-windres": executable file not found in $PATH
Debug output:
[✗] could not package the Fyne app: exit status 1
make: *** [Makefile:54: windows] Error 1
Running
I don't have any M1 mac to test that part on, but the following systems have been tested:
- Linux 5.11.3 on amd64: No issues
- macOS 10.13 on amd64: No issues
- FreeBSD (GhostBSD) 12.2 on amd64:* No issues
- Windows 10 on amd64: Could not test. See compilation section above.
|
Thanks @Jacalz going to check the error on windows. Btw it seems from first tests that using the Command_Line_Tools_for_Xcode works, at least on complilation side (does not have macOS >= 10.12 to test it). |
If you have any patch for getting that working, I’ll happily test it out on 10.13 🙂 |
|
This might not be the most elegant solution out there (with all talk about not downloading random binaries from the internet). However, if anyone want to help out and test Darwin arm64 binaries on M1 machines without having to compile the fyne-cross images, I have a binary available for download here: Jacalz/rymdport#7 (comment) |
|
@Jacalz It is failing to start:
|
Actually I run it from the finder and from command line. It reports damaged file in both cases. |
I checked the system log file. Seems like MAC security is not allowing this command to run: Is this process trying to access some protected data? |
|
Another user reported a similar error on M1. Jacalz/rymdport#7 (comment) |
It shouldn’t, as far as I know. We should probably try with something else than my project to be sure (fyne_demo perhaps). I just added a binary as I was compiling it to test fyne-cross. |
|
@lucor If we are stopping to use the docker/golang-cross image for Darwin and Windows, should we maybe stop using it altogether? The Linux support shouldn’t be too hard to wire up as is and FreeBSD doesn’t really use the either way. Just a thought 🙂 |
The latest BigSur OS is very strict. You can't even exec ps command from the app. |
Updated the PR descrition, we already do this :) The dependency from docker/golang-cross hase been removed from the base image.
Agreed, test with a minimal "hello world app" would be great. |
|
I ran |
|
Here is a test compile of the hello world example of https://github.com/fyne-io/fyne/blob/develop/cmd/hello/main.go: If any M1 users want to check if it works. |
No luck. |
|
Updated to Go v1.16.2 in c95deca |
|
Root cause could be the wrong macos min version used to compile for arm64, updated in 0d36b99
|
|
Here are two new M1 test applications for testing. One is without debug and the other is with debug symbols: |
|
Things are looking much better now. I am getting the same deprecation warnings as fyne-io/fyne#1833, which I take as a good sign that the binaries are correctly built 🙂 |
Are these binaries signed with developer profile? OS not even ask to allow execute the app, just ask to move directly to a trash bin. |
|
Check this article. Perhaps adding entitlement com.apple.developer.endpoint-security.client will solve security issue. |
|
Oh, great! So it looks like is working :-) With regard to the warning above, this is expected. Go is using an ad-hoc signature, so unless you sign again the binary with a cert with a vality identity it cannot pass through Gatekeeper (see golang/go#42684 (comment) and the official docs https://developer.apple.com/documentation/macos-release-notes/macos-big-sur-11_0_1-universal-apps-release-notes#Code-Signing for details) Details on how open a developer-signed or notarized app can be found on the apple support site: https://support.apple.com/en-us/HT202491 The plan is to found a way to sign the binary using a valid cartificate directly from linux, but I'd say that this is another issue. On macOS you would sing using a developer certificate using either the @zdima could you please confirm if it runs after allowing the execution from an unidentified developer? |
|
That is the thing. Latest Big Sur don't have an option to run the app from unidentified source. I am not getting "Open anyway" option and can't find if I can enable it. |
|
Did you tried by any chance the steps reported from the macOS user guide: https://support.apple.com/guide/mac-help/open-a-mac-app-from-an-unidentified-developer-mh40616/mac ?
|
|
Yes. I did. Multiple times. |
|
I found this article https://www.kencochrane.com/2020/08/01/build-and-sign-golang-binaries-for-macos-with-github-actions/. It might be kind of useful. However, it still looks like you need a paid developer account to be able to get signing certificates https://developer.apple.com/support/compare-memberships. |
It could be, but it is hard to debug without a physical access to an M1 :-( @zdima To check if the if the signature is valid could you please run:
Yes, it works as reported by @Jacalz above. The restriction applies only to latest macOS on M1 |
Though, we should keep in mind that it was tested on MacOS 10.13. Someone running Big Sur on an amd64 machine should probably test as well. I think @andydotxyz has one? |
This is output: |
Thanks @zdima. This is weird... as per the official doc the signature is valid for the policy:
Let's try to recap where we are so far:
Issue: we are unable to run on macOS 11.x arm64 a cross-compiled app with fyne-cross on macOS amd64 due to Gatekeeper policy issues. We have not found a way yet to open an app from an unidentiefied developer despite the doc says it should be possible. Things comes in mind to debug the issue above:
Missed something ? Any additional ideas ? |
Current build tools work on BigSur for x86_64 yes - no signing required (though you will get warnings if the file was downloaded without signing). |
|
Obviously on an x86_64 BigSur those built M1 binaries won't run. |
|
Thanks @lucor. That works now 👍 |
|
Here is a new M1 test applications for testing: test.zip It tries a possible fix for the linker. |
|
The PR has been closed automatically by mistake :( |
This PR add support for the darwin arm64 target along with the following changes:
darwin-imagecommand to build the darwin docker imageFixes #33
To test the darwin image:
make baseto build the newfyneio/fyne-cross:base-latestimage with Go 1.16.x (Note this step is needed until the new base image is released and published on dockerhub)fyne-cross darwin-image --xcode-path /path/to/Command_Line_Tools_for_Xcode_<version>.dmgTo test the windows image:
make baseto build the newfyneio/fyne-cross:base-latestimage with Go 1.16make windowsto build thefyneio/fyne-cross:windows-latestimage