[NativeAOT] Compile Error on M1 Mac - Missing OSX-ARM64 Runtime Package

[jamsoft]

I've just started testing my AOT build process on mac and immediately crashed into this error:

error : Add a PackageReference for 'runtime.osx-arm64.Microsoft.DotNet.ILCompiler' to allow cross-compilation for x64 

Problem is, I cannot find this package or refereneces to it anywhere. Seems like the only permutation I can't find. But there is some talk of it being worked on.

Is there any workaround until it's available? Like forcing it to do an Intel build?

The runtime switch I'm currently using is --runtime osx-x64 but it's building on an M1 Mac Mini so it seems to be trying to do an ARM64 build ... ?!

According to the docs here:

https://github.com/dotnet/runtimelab/blob/feature/NativeAOT/docs/using-nativeaot/compiling.md

You can compile ARM64 on a x64 processor and vice versa for Windows and Linux but it doesn't really mention OSX. Can you do OSX x64 on an M1 mac or am I going to have to source a mac with an intel chip? :/

[jkotas]

We are focused on Windows/Linux, x64/arm64 for .NET 7.

Enabling OSX arm64 is tracked by #64337.

You can compile ARM64 on a x64 processor and vice versa for Windows and Linux but it doesn't really mention OSX. Can you do OSX x64 on an M1 mac or am I going to have to source a mac with an intel chip? :/

The workaround is to build x64 on OSX m1 is:

• build in x64 shell (e.g. run arch --arch x86_x64 /bin/sh)
• explicitly reference the nativeAOT package https://github.com/dotnet/runtime/blob/main/src/coreclr/nativeaot/docs/compiling.md#using-daily-builds (do not use PublishAot property to get the nativeAOT package referenced implicitly)
• Pass /p:IlcHostArch=x64 to the build (e.g. dotnet publish -c Release -r osx-x64 /p:IlcHostArch=x64

[jkotas]

Let's use this issue to track a fixing this.

[jamsoft]

Excellent!! Thank you so much. I'll get all this going today and report back.

[jamsoft]

So I think I have it working!

Switch the terminal to x64 "mode":

$env /usr/bin/arch -x86_64 /bin/zsh —-login
$arch

Outputs i386 instead of arm64

Then executing the compile:

dotnet publish MyApp.csproj -c:Release  --runtime osx-x64 -v:m --self-contained true /p:IlcHostArch=x64 

Seems to have completed!

I'm subsequently using dotnet-bundle to package up into a ".app" package so I need to confirm all that is working (it launches fine!) and using the expected AOT compiled bits rather than just the output of the initial build.

Thanks again for all your help with this. It's really appreciated.

[jamsoft]

My primary goal for using NativeAOT was leaning towards protection through the lack of IL code. Size wasn't really so much of an issue. Startup improvements etc would be nice-to-haves.

The problem is that now my circa.100Mb application has ballooned into a 1.4Gb behemoth, start up time isn't great either. I was expecting a larger executable but 1.4Gb is a bit unruly. On Windows I'm ending up with a c.300mb exe.

I've clearly still got some work to do or have explicitly included too much in my rd.xml file.

I must admit that I have pieced together my rd file from many sources and trial and error. I'm wondering if things like this are to blame?

<Assembly Name="netstandard" Dynamic="Required All">

What would be the advice in such a situation?

[jkotas]

Yes, pinning all types in large assemblies is going to bloat your AOT binary.

Another common source of code bloat are generics heavy libraries like #71333.

[jamsoft]

Yeah, it took a long time for me to nail AOT for generics, particularly EFCore. Gonna go review my rd now I have a working baseline.

[MichalStrehovsky]

#67232 (comment)