koobas.hobune.stream
Is it possible to generate the .s files for AOT compiled dll's outside of Unity?
I am trying to use a pure .NET dll that fails AOT compilation for iOS. This has been submitted to Unity as a bug but I want to move forward in the meantime. More modern versions of Mono can AOT compile the dll just fine using:
mono --aot=static,asmonly FSharp.Core.dll
and then I tried
mono --aot=mtriple=armv7-ios,static,asmonly,nodebug,full FSharp.Core.dll
This produces the FSharp.Core.dll.s file that you would expect. I then take that file and replace the FSharp.Core.dll.s file in the XCode project that has errors in it from Unity's failed AOT attempt. I then run the app and it hangs in RegisterMonoModules.cpp in the RegisterMonoModules function on:
mono_aot_register_module(mono_aot_module_FSharp_Core_info); // Thread1: EXC_BAD_ACCESS (code=1, address=0x5d)
If I inspect the assembly generated by mono vs the assembly generated by Unity's AOT there are some differences, Unity compiled files start like this:
#if defined(__arm__)
.text
.align 3
methods:
.space 16
.align 2
...
Direct Mono compiled files (using the second command given above):
.text
.align 3
methods:
.space 16
.text
.align 4
L_m_0:
...
I'm guessing Unity invokes the mono AOT in a slightly different manner than I am doing, hopefully not in a super customized way. Does anyone know the compiler flags I would need to duplicate Unity's compiled versions or if there are any other problems that await me should that succeed?
It's not possible to use a different mono version than unity uses. Newer mono is very likely to be incompatible with the mono runtime that Unity uses - the data layout may be different, new internal functions may be called, etc. Any such incompatibilities may lead to loss of features at best and a crash at worst. Unfortunately here we're observing the latter case.
