I also made sure my MONO_PATH points to the Xamarin.Mac framework path if that matters.
Try AOT compiling using /Library/Frameworks/Xamarin.Mac.framework/Commands/bmac-mobile-mono instead of system mono.
I'll explain what i think is going on in a second...
When you build a Xamarin.Mac application, one of the steps to to link mono into your launcher application. We use the libraries stored here:
Which is very very likely a slightly different version that your system mono.
As you can see we ship and use a different mono (which is poorly named) when we AOT XM:
@ChrisHamons Same problem unfortunately...
Ok, let's lay out the problem.
And you are doing the following?
Are you getting the same error?
Chris, that's exactly what I'm doing, except for "Enable AOT on your XM settings". I'm not sure what XM setting you're referring to.
Are you AOT'ing your Xamarin.Mac output by hand? Or are you just AOTing the plugins and not your main application?
Yes, I'm only AOTing my plugins, not the main app.
This is what I'm executing in a terminal: MONO_PATH=/Library/Frameworks/Xamarin.Mac.framework/Versions/Current/lib/mono/4.5 /Library/Frameworks/Xamarin.Mac.framework/Commands/bmac-mobile-mono --aot=static DependencyLibrary.dll
MONO_PATH=/Library/Frameworks/Xamarin.Mac.framework/Versions/Current/lib/mono/4.5 /Library/Frameworks/Xamarin.Mac.framework/Commands/bmac-mobile-mono --aot=static DependencyLibrary.dll
Hmm. Are you still getting the same error:
error: * Assertion at /Users/builder/data/lanes/4466/a04678c2/source/xamarin-macios/external/mono/mono/mini/aot-runtime.c:2300, condition 'info->version == MONO_AOT_FILE_VERSION' not met
Yep, just checked again.
If we can switch to email, I'd be happy to share my sample project.
Sure. I'll message you it.
Are you passing the value of the 'mono_aot_module_..._info' symbol to mono_aot_register_module () ? If you are loading it using dlsym (), you need to do an additional indirection, i.e.
void **addr = dlsym ("....");
That gets rid of the crash! So, one step closer! But I still can't see symbols for calls into my AOT'd library in Instruments... =(
I tried to compile my project with the --aot=all option and no problems at compilation.
I'm in framework mobile.xamarin.mac
Can I use this in production and is it really more efficient ?
So you can read about AOT here (https://medium.com/@donblas/ahead-of-time-compilation-with-xamarin-mac-ceb6fb1d0a3c), though it was more experimental when I wrote it, but the short answer is that there are two areas where AOT help:
Better "native" crash logs. If your application crashes in native code, which is common occurrence when you look at Cocoa the wrong way, native crash logs with JIT frames are difficult to analyze. Since the JIT frames do not have debug information, you'll see multiple lines with hex offsets and no clue what was going on. AOT generates "real" named frames and the traces are much easier to read. This also means we interact better with native tools such as lldb and Instruments.
Better launch time performance. If you have a "large" application, with a multiple second startup time, JITing all of your code can take a significant amount of time. AOT does this work up front.
What it won't do is improve "general" program performance" Most applications are not bound by JIT time during use and won't see much change after launch.
Oh, and to answer your question on "is it safe". The best answer I can give you is "likely". The AOT code generator in mono is battle tested and I have seen Xamarin.Mac integration with AOT specific bugs.
However, the feature only had moderate QA testing and few users tested it in the field so far. This is why the documentation still marks it as "experimental".
I know of no reason why you shouldn't ship with it enabled if things work, but that's the background.
Thank you for the answer.
Can you tell me if the problem of -register = dynamic is solved because when I posted my application to apple, it was refused because I was using a library that was not even in my project.
I had to reset -register = static to move the application to the AppStore.
@RogisterAlain We're becoming increasingly off topic (and should start another thread) but no - if you use XM Full (4.5) target framework and are submitting to the app store, you have to use --registrar=dynamic for now.
I wrote more details here:
sorry but thanks for the answer
I come back to you for the AOT compilation.
For several months now, my application crash randomly to different places, not often in the same place, for no apparent reason and the log report does not know the real problem. So it's really annoying.
I tried the AOT compilation by putting as parameter: --aot = all
I compile and there, MIRACLE, my application no longer crashes at all. I can work with for hours.
Do you have an explanation for that ? Is this a bug with Xamarin's JIT ?
I can think of a number of explanations, but without data, they are only wild guesses. In order of likelihood:
If you track down more information, with a small reproducible sample, please file a bug at bugzilla.xamarin.com
thank you for the answer
I still think the crash problems I encounter are problems with "bad" memory management.
An example: I have a toolbar with a button and when I click on it, I change the content of the view. It works all the time and sometimes, when I click on the button, it crashes. Sometimes I can do it dozens of times and no problem. Sometimes, after 2 clicks, it crashes.
This is an example but often when I click a button that opens a new window or changes the view in a single window.
This is impossible to reproduce with a small application. I think as you say it is due to the code that is specific to this window.
It is true that in this application, there are many network calls (webservice), a lot of timer management, maybe it comes from there. I do not know.
Xamarin Inc., as a wholly-owned Microsoft subsidiary acting as a separate legal entity, adheres to the Microsoft Privacy Statement: Privacy & cookies