Release arm64 binary or universal binary for macOS

[wAuner]

Hi,

could you please publish release binaries for M1 / arm64 on macOS as well? Cross compiling should be relatively trivial (I hope).
I haven't tested it yet, but it looks like all that's needed are the two variables GOOS=darwin GOARCH=arm64 when running the compilation command.
Universal binaries (binaries that contain both x86_64 and arm64 code) don't seem to be supported yet (at least not out of the box by the go compiler), but it should still be possible with very little effort, see here. But I'm not sure whether you need a mac for creating a universal binary this way. But even if there were two separate binaries for macOS, that'd still be great.

Let me know if you need help.

[wAuner]

It's been quite some time since I've last worked with go so I don't know much about the toolchain, but I've installed the latest go version and tried to compile klog on M1. These are the errors I get:

╰─$ GOOS=darwin GOARCH=arm64 /usr/local/go/bin/go  build src/app/cli/main/klog.go

# github.com/jotaen/klog/lib/caseymrm/menuet
lib/caseymrm/menuet/menuitem.go:50:10: undefined: Application
lib/caseymrm/menuet/menuitem.go:52:11: assignment mismatch: 2 variables but 1 value
lib/caseymrm/menuet/menuitem.go:90:10: undefined: Application
lib/caseymrm/menuet/startup.go:14:10: undefined: Application
lib/caseymrm/menuet/startup.go:26:10: undefined: Application
lib/caseymrm/menuet/startup.go:38:10: undefined: Application
lib/caseymrm/menuet/startup.go:48:10: undefined: Application
lib/caseymrm/menuet/update.go:30:10: undefined: Application

I've previously build klog successfully for x86_64.
Any idea what went wrong here?

[jotaen]

Hey, yeah supporting ARM is a good idea indeed. I don’t have an M1 (yet), so I didn’t get a chance of trying it myself.

I suppose eventually the universal binary would be most convenient, and it seems like lipo is available on the Github workflow runner, so hopefully it’s possible without too much additional fuss.

The error you see is from the systray widget (klog widget), which compiles some Objective-C under the hood for the native UI. I use a (slightly modified) 3rd-party library for that, and it looks like it doesn’t support ARM architectures. The library itself is likely abandoned, so I don’t expect them to add ARM support anytime soon, if at all. So I need to see what I do about this.

The compile command you use looks correct, but you need to exclude the widget from the compilation. Could you try running it again, but replace the first two lines in this file with //go:build !(darwin && amd64)? That should exclude the widget from anything but AMD on Darwin (Mac). (See comment below.)

[jotaen]

Oh and maybe you need to delete the run_darwin.go file additionally. (See comment below.)

[jotaen]

I’ve fixed the build directives, so running the compile command should work now.

[wAuner]

That worked well! I compiled and checked the build:

╰─$ GOOS=darwin GOARCH=arm64 /usr/local/go/bin/go  build src/app/cli/main/klog.go

╰─$ file klog
klog: Mach-O 64-bit executable arm64

[wAuner]

The error you see is from the systray widget (klog widget), which compiles some Objective-C under the hood for the native UI. I use a (slightly modified) 3rd-party library for that, and it looks like it doesn’t support ARM architectures. The library itself is likely abandoned, so I don’t expect them to add ARM support anytime soon, if at all. So I need to see what I do about this.

Wouldn't it be possible to get that working as well? Compiling Objective C to arm64 should be easy. We would just need to figure out how this thing is build.

I've tried to compile the objective c files, but I get multiple warnings about deprecated macOS APIs, so sooner or later it probably won't work anymore anyway.

╰─$ clang -x objective-c -c -arch arm64 menuet.m
menuet.m:213:36: warning: 'NSUserNotificationCenter' is deprecated: first deprecated in macOS 11.0 - All NSUserNotifications API should be replaced with UserNotifications.frameworks API [-Wdeprecated-declarations]
        [[NSUserNotificationCenter defaultUserNotificationCenter] setDelegate:d];
                                   ^
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/System/Library/Frameworks/Foundation.framework/Headers/NSUserNotification.h:118:12: note: 'NSUserNotificationCenter' has been explicitly marked deprecated here
@interface NSUserNotificationCenter : NSObject {
           ^
menuet.m:230:33: warning: 'NSUserNotificationCenter' is deprecated: first deprecated in macOS 11.0 - All NSUserNotifications API should be replaced with UserNotifications.frameworks API [-Wdeprecated-declarations]
- (void)userNotificationCenter:(NSUserNotificationCenter *)center didActivateNotification:(NSUserNotification *)notification {
                                ^
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/System/Library/Frameworks/Foundation.framework/Headers/NSUserNotification.h:118:12: note: 'NSUserNotificationCenter' has been explicitly marked deprecated here
@interface NSUserNotificationCenter : NSObject {
           ^
menuet.m:230:92: warning: 'NSUserNotification' is deprecated: first deprecated in macOS 11.0 - All NSUserNotifications API should be replaced with UserNotifications.frameworks API [-Wdeprecated-declarations]
- (void)userNotificationCenter:(NSUserNotificationCenter *)center didActivateNotification:(NSUserNotification *)notification {
                                                                                           ^
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/System/Library/Frameworks/Foundation.framework/Headers/NSUserNotification.h:24:12: note: 'NSUserNotification' has been explicitly marked deprecated here
@interface NSUserNotification : NSObject <NSCopying> {
           ^
menuet.m:231:44: warning: 'NSUserNotificationActivationTypeReplied' is deprecated: first deprecated in macOS 11.0 - All NSUserNotifications API should be replaced with UserNotifications.frameworks API [-Wdeprecated-declarations]
        if (notification.activationType == NSUserNotificationActivationTypeReplied) {
                                           ^
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/System/Library/Frameworks/Foundation.framework/Headers/NSUserNotification.h:15:28: note: 'NSUserNotificationActivationType' has been explicitly marked deprecated here
typedef NS_ENUM(NSInteger, NSUserNotificationActivationType) {
                           ^
4 warnings generated.

[jotaen]

Awesome, thanks for verifying, and also for fiddling around and sharing your findings.

I’ve extended the automated builds now to generate separate versions for both Intel (AMD) and ARM. I’ve also edited the latest v3.1 release, so you find the ARM binary there for download.

I didn’t go with universal binaries in the end, because the resulting binary size came out quite big with lipo. It basically just concatenated the two binaries, which resulted in 2 * 9MB = 18 MB. Not that anyone would care about such a file size nowadays, but I still find that a bit … unaesthetic. I’ll keep it in mind anyways, perhaps there will be better ways that yield more efficient binaries, so I might come back to this.

Regarding the widget, the situation is a bit tricky: I personally don’t use the widget anymore, and I also don’t think a lot of other people do. Unfortunately, the current approach is also very limited, so I feel it’s a dead end overall. I don’t mind keeping the code as it is, because it works (well, on Intel Macs at least) and it doesn’t do too much harm right now. But instead of investing time into extending or porting, I’d rather reimplement it properly and make it more powerful – not sure, admittedly, whether that will ever happen.

That being said, if you or anyone else is in the mood to fix the current code to make it work on ARM, I’d be open for pull requests.