Exiting an Apple Silicon build results in an infinite loop

[tomkidd]

Hey guys, I got ECWolf building on Apple Silicon (the M1 processor) and the good news is the game works great… until you try and exit, where it hangs until you kill the process.

Long story short, it’s getting stuck when it tries to write out the config file

https://bitbucket.org/ecwolf/ecwolf/src/ac4a22947240db067021e55f437c0ea29844760c/src/zstrformat.cpp#lines-693

The atob call drills down into this code from one of the dependencies that results in an infinite loop

https://bitbucket.org/ecwolf/ecwolf/src/ac4a22947240db067021e55f437c0ea29844760c/deps/gdtoa/misc.c#lines-305:318

My guess is this has something to do with a difference in how an arm64 processor handles things.

Before I try and figure this out I thought I’d post it here to see if anyone has any ideas.

[Braden Obrzut]

Although I’ve been too busy to follow what the fix was, this sounds familiar to something GZDoom encountered. Possibly this? https://github.com/coelckers/gzdoom/commit/0036f7fadea94459a58d8ad3401341d5a888f151#diff-86ddb18a08b655fbc051f50a1149a1978b10c2e40a4db10da2f8c08799038a7a

[tomkidd]

That seems to have done the trick, thanks.

Once I get a Universal 2 build going I’ll do a PR.

https://bitbucket.org/macsourceports/ecwolf/commits/fd19392932e92a15c5ed59217e8b81d131a2f98c

[Braden Obrzut]

Copying the target_link_libraries call like that is an old CMake practice that no longer needs to be done. You should be able to make a target_link_libraries call containing only AppKit a little higher up in the file (near where BUILD_BUNDLE is defined).

As for building a universal binary, I personally found supporting a one pass build to be too much of a hassle (especially in my case since I have a tendency to need to use completely different compilers for different architectures anyway). None of the issues are technically un-fixable, but I had enough situations where the PowerPC version worked fine if built alone and didn’t if built directly as a universal binary. The way universal builds are supported in ECWolf today is to just have two (or I guess three now) separate builds and then use the lipo tool to combine them.

I mean feel free to make it work if you’re so inclined, if it’s not too much of a mess I’ll pull it. Just letting you know how I do the builds.

[tomkidd]

Thanks, I’ll try that with CMake.

And yeah, the way I go about it I do the x86_64 and arm64 builds and then lipo them together and call it a Universal 2 bundle (with PPC/x86/x86_64 bundles being retronymed Universal 1)

[Braden Obrzut]

Can’t say I’m a huge fan of the Universal 2 naming. I mean given that ECWolf still compiles and runs on PowerPC, if I release a ppc/x86/x86_64/arm64 binary, what would you call that?

[tomkidd]

According to Apple’s guidelines/marketing:

Universal Binary: PPC/x86/x86_64

Universal 2 Binary: x86_64/arm64

I think the idea is they align to the transitions - Universal was for the PPC → Intel transition, Universal 2 is for the Intel → Apple Silicon transition.

Technically you could lipo a single binary with all four, PPC/x86/x86_64/arm64, but there’s no official blessed name for that and the logistics would be tricky to pull off. Using just the Apple tools as far as I know you can’t build all four architectures on the same machine since PPC and x86 (32-bit only) support has been dropped from modern Xcode and the old versions obviously won’t know about arm64. You’d need to have two different Macs build them and then coordinate them on a network share.

In any event my site uses Universal 1 and Universal 2 (“Universal 1” isn’t an official thing). I’ve just added a signed and notarized Universal 2 build for ECWolf since your suggestion about the GZDoom issue fixed the issue with an Apple Silicon native build.

https://macsourceports.com/game/wolf3d

[Braden Obrzut]

Nah, you can totally build PowerPC binaries with Big Sur (haven’t tried with Monterey yet, but I’m like 99.9% sure it will work there too). The tool chain is 64-bit binaries (obviously since it works on Big Sur) so no reason it wouldn’t work on an M1 Mac either. Even wrote an article on how to get a modern GCC cross compiler setup: http://maniacsvault.net/articles/powerpccross

Nice to hear that it’s running fine on the M1 with that fix.

Edit: Oh and in case you didn’t see my blog, Apple will even let you notarize a 4 way binary which surprised me.

[tomkidd]

Interesting, I will have to check that out, thanks.

[Braden Obrzut]

Integrated the gdtoa changes in f96c5c7.