Notice (2018-05-24): bugzilla.xamarin.com is now in
Please join us on
Visual Studio Developer Community and in the
Mono organizations on
GitHub to continue tracking issues. Bugzilla will remain
available for reference in read-only mode. We will continue to work
on open Bugzilla bugs, copy them to the new locations
as needed for follow-up, and add the new items under Related
Our sincere thanks to everyone who has contributed on this bug
tracker over the years. Thanks also for your understanding as we
make these adjustments and improvements for the future.
Please create a new report on
Developer Community or GitHub with
your current version information, steps to reproduce, and relevant error
messages or log files if you are hitting an issue that looks similar to
this resolved bug and you do not yet see a matching new report.
Created attachment 18984 [details]
I've faced with "Could not AOT the assembly" problem.
I know there are a lot of reports about such bug, but nothing from suggested tips and tricks didn't work for me(
The issue is that I have a binding project for Objective-c framework (fat framework), and when I'm trying to use the generated .dll in iOS application I'm getting this error.
In attachment you can find the BuildLog file.
Also here is the linkWith.cs code from my binding project
target: LinkTarget.Arm64 | LinkTarget.ArmV7 | LinkTarget.ArmV7s | LinkTarget.Simulator | LinkTarget.Simulator64,
SmartLink = true,
ForceLoad = true,
LinkerFlags = "-lxml2 -ObjC",
Frameworks = "Foundation OpenGLES QuartzCore UIKit")]
And my Xamarin info:
Xamarin Studio Community
Version 6.1.3 (build 19)
Installation UUID: 8006bafd-6d9f-4cac-a5b3-5307bba46ea4
Mono 4.6.2 (mono-4.6.0-branch/ac9e222) (64-bit)
GTK+ 2.24.23 (Raleigh theme)
Package version: 406020016
Apple Developer Tools
Xcode 8.2.1 (11766.1)
Version: 10.3.1.7 (Xamarin Studio Community)
Build date: 2016-12-18 12:23:27-0500
I'm also working on the same team as Yaroslav above.
We found one of the errors in the build log:
> Type SciChart.iOS.Charting.SCIGenericType/Data which has an [ExplicitLayout] attribute cannot have a reference field at the same offset as another field.
We've fixed this and it reduces the number of AOT related build errors from 2 to 1. However, still one remains.
Here is an updated build log at Onedrive: https://1drv.ms/t/s!AjQxIVxoV2Ypg4YP_JPAcZF92KLAcQ
Also a related Stackoverflow questions: http://stackoverflow.com/questions/41417230/mtouch-error-mt3001-could-not-aot-the-assembly-iphone-debug-build-iphone7-1-10
We don't see anything in there related to our code which would cause AOT to fail.
It looks like the AOT compiler crashed when trying to AOT-compile the executable:
AOT Compilation exited with code 139, command:
MONO_PATH=/Users/aburnettthompson/Documents/SciChart.Xamarin/trunk/src/Xamarin.Examples/Xamarin.Examples.Demo.iOS/obj/iPhone/Debug/build-iphone7.1-10.1.1/mtouch-cache/Build /Library/Frameworks/Xamarin.iOS.framework/Versions/10.3.1.7/bin/arm64-darwin-mono-sgen --debug -O=gsharedvt --aot=mtriple=arm64-ios,data-outfile=/Users/aburnettthompson/Documents/SciChart.Xamarin/trunk/src/Xamarin.Examples/Xamarin.Examples.Demo.iOS/obj/iPhone/Debug/build-iphone7.1-10.1.1/mtouch-cache/Xamarin.Examples.Demo.iOS.arm64.aotdata,static,asmonly,direct-icalls,full,soft-debug,dwarfdebug,no-direct-calls,outfile=/Users/aburnettthompson/Documents/SciChart.Xamarin/trunk/src/Xamarin.Examples/Xamarin.Examples.Demo.iOS/obj/iPhone/Debug/build-iphone7.1-10.1.1/mtouch-cache/Xamarin.Examples.Demo.iOS.exe.arm64.s "/Users/aburnettthompson/Documents/SciChart.Xamarin/trunk/src/Xamarin.Examples/Xamarin.Examples.Demo.iOS/obj/iPhone/Debug/build-iphone7.1-10.1.1/mtouch-cache/Build/Xamarin.Examples.Demo.iOS.exe"
Please zip up and attach your project, so that we can reproduce this ourselves (and fix it).
Thanks for your response! Our code is published on Github at https://github.com/ABTSoftware/SciChart.Xamarin.Examples (its public)
You can clone the repo and build it in VS2015/Xamarin Studio.
You should see the AOT error when building Xamarin.Examples.Demo.iOS for target iPhone.
The SciChart.iOS.Charting.dll (binding library) is hosted on NuGet. You will need to add this feed to your Visual Studio or Xamarin Studio:
With that you should be able to pull SciChart.iOS.Charting.dll and build the project.
If you need the source of the binding library, just shout. We will zip up something and attach to the ticket.
I can reproduce this.
The AOT compiler crashes with this stack trace:
* thread #1: tid = 0x30af0a, 0x00000001001a53c9 arm64-darwin-mono-sgen`mono_metadata_generic_inst_hash(data=0x8000001100000008) + 41 at metadata.c:1475, name = 'tid_307', queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=EXC_I386_GPFLT)
frame #0: 0x00000001001a53c9 arm64-darwin-mono-sgen`mono_metadata_generic_inst_hash(data=0x8000001100000008) + 41 at metadata.c:1475
frame #1: 0x00000001001ab90c arm64-darwin-mono-sgen`mono_metadata_generic_context_hash(context=0x00000001070c7eb0) + 60 at metadata.c:4821
frame #2: 0x00000001001b0ad1 arm64-darwin-mono-sgen`inflated_method_hash(a=0x00000001070c7e70) + 33 at metadata.c:2193
frame #3: 0x00000001003329bd arm64-darwin-mono-sgen`do_rehash(hash=0x0000000101a12560) + 157 at ghashtable.c:205
frame #4: 0x00000001003316db arm64-darwin-mono-sgen`rehash(hash=0x0000000101a12560) + 139 at ghashtable.c:225
frame #5: 0x000000010033150a arm64-darwin-mono-sgen`monoeg_g_hash_table_insert_replace(hash=0x0000000101a12560, key=0x0000000105c163b0, value=0x0000000105c163b0, replace=0) + 138 at ghashtable.c:241
frame #6: 0x000000010012cbeb arm64-darwin-mono-sgen`mono_class_inflate_generic_method_full_checked(method=0x00000001070144f0, klass_hint=0x0000000000000000, context=0x00007fff5fbfe390, error=0x00007fff5fbfe3a0) + 1659 at class.c:1178
frame #7: 0x000000010012c564 arm64-darwin-mono-sgen`mono_class_inflate_generic_method_checked(method=0x00000001070144f0, context=0x00007fff5fbfe390, error=0x00007fff5fbfe3a0) + 52 at class.c:1015
frame #8: 0x00000001000c9d54 arm64-darwin-mono-sgen`mini_get_shared_method_full(method=<unavailable>, all_vt=<unavailable>, is_gsharedvt=0) + 340 at mini-generic-sharing.c:3478 [opt]
frame #9: 0x000000010009cb34 arm64-darwin-mono-sgen`add_extra_method_with_depth(acfg=0x0000000106006a00, method=0x0000000105c087d0, depth=4) + 52 at aot-compiler.c:3547 [opt]
frame #10: 0x000000010009e7f8 arm64-darwin-mono-sgen`compile_method(acfg=<unavailable>, method=<unavailable>) + 1976 at aot-compiler.c:7617 [opt]
frame #11: 0x0000000100090b95 arm64-darwin-mono-sgen`mono_compile_assembly [inlined] compile_methods + 299 at aot-compiler.c:9833 [opt]
frame #12: 0x0000000100090a6a arm64-darwin-mono-sgen`mono_compile_assembly(ass=<unavailable>, opts=<unavailable>, aot_options=<unavailable>) + 14010 at aot-compiler.c:10594 [opt]
frame #13: 0x0000000100086671 arm64-darwin-mono-sgen`mono_main + 148 at driver.g.c:1098 [opt]
frame #14: 0x00000001000865dd arm64-darwin-mono-sgen`mono_main(argc=<unavailable>, argv=<unavailable>) + 7501 at driver.g.c:2171 [opt]
frame #15: 0x0000000100001664 arm64-darwin-mono-sgen`main [inlined] mono_main_with_options(argc=<unavailable>, argv=<unavailable>) + 17 at main.c:45 [opt]
frame #16: 0x0000000100001653 arm64-darwin-mono-sgen`main(argc=6, argv=<unavailable>) + 1811 at main.c:338 [opt]
frame #17: 0x0000000100b60255 libdyld.dylib`start + 1
frame #18: 0x0000000100b60255 libdyld.dylib`start + 1
I'm setting milestone to C9 since it happens on the cycle9 branch as well.
Thank you, you are a lifesaver :)
If you need anything else from us please feel free to ask. Can supply full binding lib sources privately.
PS: We're getting a number of other BTouch errors in Cycle 9 Alpha. I realise its an Alpha but if you could keep an eye out for these issues as well with our library, I would really appreciate it.
We're hoping to release SciChart for iOS soon - a 2D high performance stock chart/scientific chart library. More to come from us in 2017 if it all works out!
@Andrew, please file any issues you run into, afaik there are no known btouch bugs for cycle9, which means that if you don't file anything we won't fix it (since we don't know about it).
Could be a dup of:
With a newer build (including the fix for #50290) I get different errors .
Since those happens at the native link stage it means the AOT compiler (where the MT3001 error came from) has completed.
The remaining errors seems related to missing architectures  as it includes only simulator architectures  where the bug could only be seen in AOT (device) builds.
A newer alpha build should be soon available. A pre-QA'ed version is available from 
 MTOUCH: error MT5209: Native linking error: warning: ignoring file /Users/poupou/git/SciChart.Xamarin.Examples/src/Xamarin.Examples.Demo.iOS/obj/iPhone/Debug/device-builds/iphone8.2-10.0.1/mtouch-cache/SciChart.framework/SciChart, missing required architecture armv7 in file /Users/poupou/git/SciChart.Xamarin.Examples/src/Xamarin.Examples.Demo.iOS/obj/iPhone/Debug/device-builds/iphone8.2-10.0.1/mtouch-cache/SciChart.framework/SciChart (2 slices)
 /Users/poupou/git/SciChart.Xamarin.Examples/src/Xamarin.Examples.Demo.iOS/obj/iPhone/Debug/device-builds/iphone8.2-10.0.1/mtouch-cache/SciChart.framework/SciChart: Mach-O universal binary with 2 architectures
/Users/poupou/git/SciChart.Xamarin.Examples/src/Xamarin.Examples.Demo.iOS/obj/iPhone/Debug/device-builds/iphone8.2-10.0.1/mtouch-cache/SciChart.framework/SciChart (for architecture i386): Mach-O dynamically linked shared library i386
/Users/poupou/git/SciChart.Xamarin.Examples/src/Xamarin.Examples.Demo.iOS/obj/iPhone/Debug/device-builds/iphone8.2-10.0.1/mtouch-cache/SciChart.framework/SciChart (for architecture x86_64): Mach-O 64-bit dynamically linked shared library x86_64
*** This bug has been marked as a duplicate of bug 50290 ***
OK so -- we need to include architecture armv7 in the native framework and then await the next alpha?
Thanks guys, really appreciate this
@Andrew you need* to add both arm7 and arm64 slices to the framework.
* for the app store Apple accept only 32/64 bits fat apps (armv7 + arm64) or a 64bits only application (arm64). The later won't work on older, 32 bits only, devices.
Oh gosh I forgot about the app store rejecting x86 slices. For our native framework we provide a script to strip out the simulator slice. I guess that won't be possible with Xamarin binding libraries
What's the consensus? Should we publish two binding libs to NuGet?
1. Production: ARM7, ARM64
2. Devx86, ARM7, ARM64
We automatically remove slices for unused architectures, so you can put as many architectures as you want in the framework.
Thank you guys for your kind help.
We are trying to build the solution now with Xamarin 10.4.0.67 Alpha. However, our main SciChart.iOS.Charting.dll binding library is now failing with a BTOUCH error so we are unable to confirm if this is fixed.
/Users/aburnettthompson/Documents/SciChart.Xamarin/trunk/src/Xamarin.iOS/SciChart.iOS.Charting/BTOUCH: Error BI0000: Unexpected error - Please file a bug report at http://bugzilla.xamarin.com (BI0000) (SciChart.iOS.Charting)
I have created a new bug #51212. Please can you have a look?
We are now able to build and AOT our Xamarin Assembly!
Steps to resolve were:
- We must build the binding library with Xamarin.iOS 10.3 Stable including ARM7, ARM64 and x86 slices
- We must run / AOT the actual demo from Xamarin.iOS 10.4.0.67 Alpha
if you get latest from https://github.com/ABTSoftware/SciChart.Xamarin.Examples it now runs on device
THIS ISSUE CAN BE CLOSED
Related issue Bug 51212 however remains open.
> We are now able to build and AOT our Xamarin Assembly!
> Steps to resolve were:
> - We must build the binding library with Xamarin.iOS 10.3 Stable including
> ARM7, ARM64 and x86 slices
If you're creating a binding library for general consumption, you might want to include ARMv7s and x86_64 as well, otherwise users who want to use those architectures won't be able to use your library.