Preparing for Apple Silicon Macs #318
Comments
|
Compilation and distribution won't be an issue, it's basically just us going back to setting CC="cc -arch x86_64 -arch arm64" and shipping the universal binaries, like the old days. For my local setup I'll most likely continue building x86_64 builds with osxcross and then lipoing that with arm64 binaries built on a Mac (until osxcross catches up). I'm up for making iOS/tvOS dllconfig files separate, since that's a whole other build process anyway. We'll have to look at how Big Sur support is doing on the SDL Bugzilla. It'll suck, but that's how it is every year. |
|
SDL is done (Needed one asm line for breakpoints and a couple fixes in the configure script), so the only change left is the dllmap. Once the stable compiler is released I'll do a rebuild of everything and we can wrap this issue up. |
|
dllmap has been updated in master and the docs have been updated alongside it. Just need the stable compiler to come out... |
|
The macOS ARM patches for Mono have been merged: |
|
osxcross has added initial support for ARM, so I've made early ARM64-only binaries for testing: http://fna.flibitijibibo.com/archive/fnalibs_osxarm.tar.bz2 All we have to do is Pulling in the Mono source to try an osxcross build now. |
|
Mono build fails in a few places, assuming this has more to do with the build host than the ARM64 support. Important details: Configure line: Git diff with all the hacked lines: I believe the only people other than us that currently care about this are the Godot team, per godotengine/godot-build-scripts#10. @akien-mga, some notes above for whenever you look at this! |
|
Thanks for the ping! CC @neikeq if you want to start poking at this for Godot. |
|
Found the issue, turns out Mono's configure scripts have a bug in them even for the official build environment where you also need to specify MonoKickstart diff, hoping this name is fixed for x86_64 as well... |
|
Latest osxcross adds the mono-codeman.c and CMakeLists.txt patches still apply. |
|
Fresh Apple Silicon builds of fnalibs are here: http://fna.flibitijibibo.com/archive/fnalibs_arm64.tar.bz2 No MonoKickstart build because the Extinguish stage for .NET kicked in and we don't have standalone Mono releases anymore - the last one did not backport Apple Silicon support so for now this is screwed until we can get everyone together to take over maintainership of Mono. |
|
I now have Universal Binaries working on flibitBuild... only had to compile Clang/LLVM from scratch. The builds are not in fnalibs.tar.bz2 yet, waiting on this report to be resolved: Once I have that I'll update fnalibs to be universal. Still no word on Mono, Steamworks, or basically anybody except for us. |
|
I've been poking at Mono 6.12.0.144 (which includes a backport of ARM64 support for the Namely that This simple example fails building: int main() {
if (__builtin_available(macOS 11, *)) {
return 1;
}
return 0;
}Edit: My bad, it does compile fine if I don't forget to specify the min macOS version ( |
|
I believe this requires building Apple's Clang/LLVM source code, but I don't totally remember - for arm64 I just made a temporary def to make it always use the path that Big Sur would use (didn't even bother with x86_64 at the time since I could just lipo it to my old build made from Mojave). Whatever the fix is, it's at least worth adding to the osxcross README. |
|
I opened tpoechtrager/osxcross#278 to keep track of that For now I'm also patching Mono to work it around, but that means not have this code running when actually running x86_64 binaries on Big Sur. diff --git a/mono/utils/mono-codeman.c b/mono/utils/mono-codeman.c
index 234aac4b..608fad42 100644
--- a/mono/utils/mono-codeman.c
+++ b/mono/utils/mono-codeman.c
@@ -666,8 +666,10 @@ mono_code_manager_size (MonoCodeManager *cman, int *used_size)
void
mono_codeman_enable_write (void)
{
-#if defined(HAVE_PTHREAD_JIT_WRITE_PROTECT_NP) && defined(TARGET_OSX)
- if (__builtin_available (macOS 11, *)) {
+#if defined(HAVE_PTHREAD_JIT_WRITE_PROTECT_NP) && defined(TARGET_OSX) && defined(TARGET_ARM64)
+ // __builtin_available only works on osxcross if min version matches the version we check,
+ // so it's pointless. Hardcode ARM64 == Big Sur or later.
+ if (1) { // (__builtin_available (macOS 11, *)) {
int level = GPOINTER_TO_INT (mono_native_tls_get_value (write_level_tls_id));
level ++;
mono_native_tls_set_value (write_level_tls_id, GINT_TO_POINTER (level));
@@ -685,8 +687,10 @@ mono_codeman_enable_write (void)
void
mono_codeman_disable_write (void)
{
-#if defined(HAVE_PTHREAD_JIT_WRITE_PROTECT_NP) && defined(TARGET_OSX)
- if (__builtin_available (macOS 11, *)) {
+#if defined(HAVE_PTHREAD_JIT_WRITE_PROTECT_NP) && defined(TARGET_OSX) && defined(TARGET_ARM64)
+ // __builtin_available only works on osxcross if min version matches the version we check,
+ // so it's pointless. Hardcode ARM64 == Big Sur or later.
+ if (1) { // (__builtin_available (macOS 11, *)) {
int level = GPOINTER_TO_INT (mono_native_tls_get_value (write_level_tls_id));
g_assert (level);
level --; |
Turns out that one needs compiler-rt for this, which is an optional build step for osxcross. Installing it solves the issue, so |
|
Can confirm that Mono and the fnalibs compile with the necessary components built and installed. At this point FNA has done everything it can to make Apple Silicon support possible, and a Mono release has Apple Silicon support officially. This is enough to produce a DRM-free build of an FNA game! However, we're still blocked by basically the entire rest of the industry:
These are all essential parts of the back catalog, and while many of these middlewares provide arm64 support for their newest version, the lack of Steamworks/Galaxy support in any capacity along with no backports for older versions make providing arm64 by default extremely difficult, since the Universal Binary means potentially running arm64 with incomplete dependencies, resulting in the game not being loadable. Having developers selectively run So, here is FNA's official plan for Apple Silicon as of now:
Do I expect stores to ship for Apple Silicon? Truthfully, I don't think so - if I were running a store my decision would be based on the outcome of Apple vs. Epic Games; if Apple wins (and, cynically, this is what I expect will happen), I would use it as an excuse to end support for the Mac since you could combine the complete loss of a massive back catalog with the inevitable move to an App-Store-only Mac, which Apple would now be 100% allowed to do (and unlike Windows 10 S it would probably actually sell). I'm keeping a close eye on what stores are doing since I still have a crapload of Mac games to support, but I'm not hopeful. |
|
Is this no longer a supported configuration? I assume that's why you removed the dependencies packages. |
|
Truthfully, another half-assed lib that claims to support Mac desktop. Please remove it from your list of supported platforms. |
|
@crjenkins did you even read any of the comments in this issue? |
Since the Apple Silicon Macs are on their way, and especially now that devkits are starting to ship, we need to figure out what all must be done to prepare for their arrival. Thankfully Apple is working on porting Mono to Apple Silicon, so that much is taken care of, but there are still several other items we'll need to figure out:
osxbinaries. (Maybe we could ship them in a newosx-armfolder?)target=osx arch=armv8lines to remap iOS libs to "__Internal". This is going to cause conflicts with the new macs, so we'll need to remove those lines. Maybe we could distribute a separate app.config file for iOS?There are probably other issues I'm not thinking of. Feel free to mention anything I missed. Thankfully we still have some time before consumer machines start shipping, so we should be able to complete all of this before then!
The text was updated successfully, but these errors were encountered: