Apple silicon support

[pingwinator]

Hi. The 1.6 version works great via roseta2 support. I have tried to build it for my self and it works. I installed dependencies via HomeBrew, but they have support only for arm (not-fat binary). Also, I tried to build it via ci scripts by adding -DCMAKE_OSX_ARCHITECTURES="arm64;x86_64" and found that sdl 2.0.14 is a fat bin, but sdl_mixer 2.0.4 not (only x86_64 build). I could build a fat binary on my mac, but I think it's better to have this solution on the CI.

[crudelios]

I agree we should support Apple Silicon, however none of us have such a system to test things on. Would you be willing to test our CI build attempts?

[pingwinator]

yes, sure. I can help with testing. I have tried to build it via ci, but the problem with sdl_mixer build. and I can't rebuild it for arm64. I used bottles from homebrew and did arm only build.

julius.dmg.zip

[bvschaik]

The problem is indeed with SDL mixer not providing an ARM-enabled build. I've opened an issue at the SDL bug tracker, hopefully they'll add support soon. If I don't hear back in a week or so I'll try to compile SDL_mixer on the CI, but I'd rather go the "official" route.

[pingwinator]

please, let me know about any updates. I want to help you with it

[crudelios]

I think there's a pending 2.0.5 release, so hopefully they'll compile with Apple Silicon support then.

[bvschaik]

I really hope they do.

I just did some experiments: we need to compile SDL_mixer as a framework using xcodebuild so we get a redistributable library, rather than a non-portable one (like homebrew). If I try to compile SDL_mixer, it complains that mpg123, vorbis, flac, etc are missing support for arm7. If I then try to build mpg123, it throws compile errors at me. Some libraries don't even have an Xcode project file, so I really wonder how one is supposed to build the .framework bundle on Mac.

The only thing we can do right now is wait for support.

[pingwinator]

I really hope they do.

I just did some experiments: we need to compile SDL_mixer as a framework using xcodebuild so we get a redistributable library, rather than a non-portable one (like homebrew). If I try to compile SDL_mixer, it complains that mpg123, vorbis, flac, etc are missing support for arm7. If I then try to build mpg123, it throws compile errors at me. Some libraries don't even have an Xcode project file, so I really wonder how one is supposed to build the .framework bundle on Mac.

The only thing we can do right now is wait for support.

you don't need arm7 support, you need only arm64 and without other flac and other formats support. ps - you could download binaries from homebrew https://formulae.brew.sh/api/formula/sdl2_mixer.json. Btw, homebrew uses the ./configure --prefix=/opt/homebrew/Cellar/sdl2_mixer/2.0.4 --disable-music-flac --disable-music-flac-shared --disable-music-mid build command. In theory could add CFLAGS="-arch arm64 -mmacosx-version-min=11.0 -arch x86_64" or only CFLAGS="-arch arm64" for build only arm build. I'm able to reproduce it, but I can't build the game with those libs (lost in search paths)

[bvschaik]

Apologies, I was mixing arm stuff up since I also do mobile Android development. It's indeed telling me: ld: symbol(s) not found for architecture arm64 for all library functions that are provided by mpg123, etc.

Using homebrew (or ./configure) is not an option since those create 'thin' libraries that cannot be redistributed to other architectures.

I'm not familiar with the xcode build system or how to disable any libraries from there, so I'd rather wait for official support in SDL_mixer instead of sinking time into this. The game works using the x86_64 bridge, so there's no urgency here.

[crudelios]

Since this an SDL_mixer issue that will be fixed by itself when support is added (I'm guessing when v2.0.5 comes along), should we keep this open? I mean, there's really nothing we can do about this.

[bvschaik]

Good question. I don't mind keeping this open a little longer. On the other hand, it doesn't look like ARM support has priority on the SDL mixer side: we can reopen this issue for testing later when support lands in the mixer library.

[crudelios]

@pingwinator The latest git build of sdl_mixer has added support for Apple M1.

Can you give it a go, compile it yourself please? Thanks!

[bvschaik]

@pingwinator I created a build, could you test this one? (DMG in zip because github doesn't allow uploading DMG files directly...) julius.dmg.zip

[pingwinator]

@pingwinator I created a build, could you test this one? (DMG in zip because github doesn't allow uploading DMG files directly...) julius.dmg.zip

unfortunately, crash on m1 and works fine via rosetta j_m1.crash.txt

[pingwinator]

lipo -info ulius.app/Contents/Frameworks/libpng16.16.dylib
Non-fat file: julius.app/Contents/Frameworks/libpng16.16.dylib is architecture: x86_64

arm64 is missing for this lib

[bvschaik]

I think the PNG lib is a leftover from a previous build, I compiled the last .app without external libs. The real reason it crashes is because the code isn't signed:

Termination Reason:    Namespace CODESIGNING, Code 0x2

I don't have an apple developer account so I cannot sign it.

Could you try compiling it yourself?

1. Check out the latest SDL_mixer source
2. Go to the xcode folder and run xcodebuild
3. Copy the resulting SDL mixer framework to a location where Julius can find it
4. Build Julius with the following cmake options: cmake -DSYSTEM_LIBS=OFF -DCMAKE_OSX_ARCHITECTURES "x86_64;arm64"

[pingwinator]

@bvschaik I tried to build the framework and the app. I have the same result. I have an apple dev account and will try to build it later with apple certificates.

[pingwinator]

@bvschaik I have found the problem. I build a framework with another recommended codesign option and it works. SDL2_mixer.framework.zip can you try build the app with this framework or build it from my fork? https://github.com/pingwinator/SDL_mixer

[bvschaik]

can you try build the app with this framework or build it from my fork? https://github.com/pingwinator/SDL_mixer

I can try but since I don't have an Apple dev certificate that will also result in an unsigned binary :(

[pingwinator]

you don't need a dev cert to build it.

[crudelios]

@pingwinator I'm not versed in mac architecture but I think the problem stems from the fact that we would like to have an automated build that would create a fat (meaning both x86 and arm compatible) binary which could be downloaded and run directly by users, which doesn't seem possible without having an Apple dev certificate.

[crudelios]

@bvschaik The latest unstable builds of sdl_mixer seem to have fat binaries of the mpg123 framework, is there age chance we could get this to work now or do we still need some sort of code signing?

[bvschaik]

Unfortunately ARM builds require code signing to work at all on macOS 😞 I'm waiting for a new official release of SDL_mixer, then I may attempt to get that set up.

[crudelios]

We can always provide mac builds as homebrew packages, granted it's not perfect but at least we skip the code signing hassle...

[bvschaik]

Homebrew is only for command-line programs. There's homebrew cask for gui apps, but I think then we still need to sign Julius.

[crudelios]

I had the idea that homebrew apps were built from source on the destination computer so they were self-signed, bypassing the need for a certificate.

[bvschaik]

Nope, they have different flavors of each program for different macos versions but the command line apps are pre-compiled. And Cask is only a package installer to make managing gui apps easier: it doesn't build and sign Chrome, for example. In short, we cannot distribute through homebrew because we are not a command line tool. And for cask we still need to sign ourselves.

[kambala-decapitator]

Unfortunately ARM builds require code signing to work at all on macOS

ad-hoc signing is sufficient, it doesn't require paid certificate. See implementation example at https://github.com/vcmi/vcmi/pull/890

Re: homebrew. It either performs ad-hoc signing when building from source or removes the "quarantine" flag during setup:

xattr -d com.apple.quarantine /path/to/bundle/or/binary

[bvschaik]

@kambala-decapitator Thanks for the pointer. I've tried to add ad-hoc signing to the macos build (in a feature branch). Could you perhaps test the build from the bottom of this page on an ARM mac? I only have access to Intel-based macs.

[kambala-decapitator]

@kambala-decapitator Thanks for the pointer. I've tried to add ad-hoc signing to the macos build (in a feature branch). Could you perhaps test the build from the bottom of this page on an ARM mac? I only have access to Intel-based macs.

seems to work: I wasn't told to move the file to Bin. (first attempt: just press ok, then launch via right-click - Open) But I don't have game files, so I didn't get past the directory selection.

[pingwinator]

lipo -info /Volumes/Julius/julius.app/Contents/MacOS/julius 
Architectures in the fat file: /Volumes/Julius/julius.app/Contents/MacOS/julius are: x86_64 arm64 

yes, it has both arch. and for run you need a right click on the file.

[bvschaik]

Thanks both for verifying, this is ready to merge then 😃