Add a build for darwin-arm64

[jedahan]

Mind making a build for apple silicon? <3

[Jacalz]

Definitely :)
That is something that I have been wanting to do, but there are a few things that need to be sorted out first. Some of these are:

• Go 1.16 should be released sometime in February with darwin-arm64 support.
• Glfw (the underlying system used by the Fyne gui library) is currently not working on M1, see glfw failing to find a service port using apple silicon. glfw/glfw#1809 and Error compiling fyne on Apple M1 arm64 fyne-io/fyne#1739 for more information.
• Builds are cross-compiled using fyne-cross and that needs support as well. If that doesn't work it should be possible to set up a local compilation environment on my iMac.

I think those are the biggest blockers currently. The big 2.1.0 release (currently in the develop branch) of wormhole-gui should be released sometime at the end of January. My plan is to hopefully have working darwin-arm64 release builds around 2.2.0 or later.

As a side-note, do you have access to an M1 mac currently? It would be great to know if the darwin-amd64 build of wormhole-gui works using Rosetta2 :)

[jedahan]

Oh, darwin-amd64 works well with Rosetta2 lol. Let's sit tight until the ecosystem catches up then.

[Jacalz]

Indeed. Thanks for confirming. Will update the README to say that it works (non-native) on Apple Silicon then 🙂

[Jacalz]

Let's keep this open please. Still hasn't been fixed ;)

[Jacalz]

There is now some effort being done to fix this upstream in Fyne. Tagging it here for future reference: fyne-io/fyne#1922

[Jacalz]

All of the necessary work for getting this done is now landed or in the process of landing.
@jedahan Do you by any chance think that you could test this macOS arm64 binary to see if it works?
wormhole-gui-dev-darwin-arm64.zip

[jedahan]

[Jacalz]

Thanks for testing. It looks like there was an issue with binaries having to be signed in order to be working. Do you think you could test this one as well?
wormhole-gui-test2-darwin-arm64.zip

[Jacalz]

Nerver mind. Looks like that isn't working either. We might need to get proper signing up and running.

[HenkPoley]

Building on M1 works fine for me 👍. On main branch, edit go.mod to use fyne v2.0.1 (the 'develop' branch will probably be fine)

#!/bin/sh

# git clone https://github.com/Jacalz/wormhole-gui.git
# cd wormhole-gui
# ./build-macos.sh

FYNE=~/go/bin/fyne
if [ ! -f "$FYNE" ]; then
    echo "$FYNE does not exist, installing now.."
    go get fyne.io/fyne/v2/cmd/fyne
fi

go clean
rm -rf ./wormhole-gui.app
~/go/bin/fyne package -icon internal/assets/icon/icon-512.png

Then start with open ./wormhole-gui.app

(I did generate the KHR header files recently and put them in include/ somewhere, may be relevant)

[Jacalz]

Thanks for the notes @HenkPoley. I appreciate it.

This is not so much an issue about wormhole-gui not being able to compile, but more of an issue with me not having an M1 computer. I need to cross-compile it and to do so, I have been using fyne-io/fyne-cross#34. There seems to be a few issues with code signing that needs to be sorted before I can compile release binaries for distribution.

[Jacalz]

Could someone please test out fyne-io/fyne-cross#34 (comment) and get back with the results in that thread? Would be great if we could try and get this solved for everyone to enjoy 🙂

[JayBrown]

By the way: the CFBundleShortVersionString in the macOS app's Info.plist has 1.0 as the version number, even though the correct version number is (currently) 2.2.0. That should be fixed for the next release.

[JayBrown]

@Jacalz: you can just ad-hoc sign macOS apps, or even use a third-party certificate not issued by Apple. These will still cause problems, however, so you could either tell users how to remove the quarantine extended attribute—i.e. xattr -dr com.apple.quarantine /Applications/wormhole-gui.app—, or tell them how to sign an app themselves—e.g. codesign --force --sign - --deep /Applications/wormhole-gui.app—, or (even better) you offer a download method that will circumvent macOS' security mechanisms. The latter would be a curl command that downloads the release zip archive directly into /Applications. Downloads performed with cURL do not receive a quarantine XA, and if the download winds up directly in an applications directory, i.e. usually either /Applications or ~/Applications, and is unzipped there, you will also have circumvented TCC. See here: https://lapcatsoftware.com/articles/without-notarization.html

[Jacalz]

By the way: the CFBundleShortVersionString in the macOS app's Info.plist has 1.0 as the version number, even though the correct version number is (currently) 2.2.0. That should be fixed for the next release.

Oh, indeed. I have just not gotten around to fixing that yet. Might require some changes to the tooling that cross-compiles the release binaries.

Sorry for the very late answer. @JayBrown That is very good information, but I’m afraid that it doesn’t lead to a very user-friendly way for the users to use this application. I think that property signed binaries (perhaps through the App Store) will be the only sensible solution. It will require some funding, but will be a very good change for the users.

[JayBrown]

Oh, I'm totally aware that this wouldn't be user-friendly. Just saying that there are other ways, but they all involve the Terminal in some way. Another thing… a question: am I correct in assuming that wormhole-gui is a stub, and that the user still needs to install the main program, e.g. with Homebrew? Then, besides signing & notarizing, it might also be a good idea to bundle that program with wormhole-gui, as the developers of Syncthing did. Then we'd have a true standalone with a simple drag&drop installation… you can't get any more user-friendly than that. ;)

[Jacalz]

Another thing… a question: am I correct in assuming that wormhole-gui is a stub, and that the user still needs to install the main program, e.g. with Homebrew? Then, besides signing & notarizing, it might also be a good idea to bundle that program with wormhole-gui, as the developers of Syncthing did. Then we'd have a true standalone with a simple drag&drop installation… you can't get any more user-friendly than that. ;)

I'm afraid that that is not correct. I am using the native Go API, so everything is compiled in to a static binary. Better for portability and better for performance. It is literally just a drag and drop already 🙂

I suggest that you have another read through the README. Feel free to mention any parts that you think should be worded differently to be more clear. I guess I should stop calling it a "graphical user interface" now that it is mature enough to be used quite regularly 😅

[Jacalz]

Good news people. It looks like binaries are working on M1, assuming that you turn off apple quarantine attribute for gatekeeper. See fyne-io/fyne-cross#39 (comment) for more information. This means that the next release will finally have M1 binaries available for download 🚀

However, these will, like the issue above kind of hints at, not be signed and thus not be valid by Apple. I still recommend sponsoring for a possible Mac App Store version in the future, but until then, you should be able to enjoy native binaries on your machines 🙂

[Jacalz]

Sorry for the long wait with this. I have been busy with a lot of other stuff. Planning to hopefully have this out with the next release in a week or two :)

[Jacalz]

This is now available in the v2.3.0 release: https://github.com/Jacalz/wormhole-gui/releases/tag/v2.3.0.

[HenkPoley]

Ah: This the quarantine stuff, that is mentioned near the download. Anyways, not useable in this state by common end-users.

---

macOS Big Sur says: wormhole-gui is damaged and cannot be opened. Move it to the trash. Unarchiver has created this file on an unknown date. Buttons: Move to trash / Cancel.

Note, Unarchiver is not shipped with macOS by default, but it is common to use. But it's native Archive tool gives a similar error:

wormhole-gui is damaged and cannot be opened. Move it to the trash. Safari has downloaded this file ..date.. on ..time.. from ..url... Buttons: Move to trash / Cancel.

[Jacalz]

Does it work if you turn of the quarantine feature? I think this post should help with that: https://discussions.apple.com/thread/3145071. Could you also try to not open it using unarchiver? The regular unarchiving application on macOS should work, I think.

I know that this is an unfortunate way to have to provide M1 binaries, but it’s what I can provide at the moment. I am a Linux user primarily and getting binaries up on the Mac App Store would mean that I need to pay for an Apple Developer Account and then most likely invest in something better than my old 2011 iMac down the line.

[Jacalz]

I have added some notes to the README in b6979ac for how to avoid the issue with binaries being marked as broken. They were basically put into quarantine as they were downloaded from the internet. Following the new guidelines should get the binaries up and running :)