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.
Debug builds for a certain app of mine fail to AOT with the following symptom:
Compiling to native code
/Developer/MonoTouch/usr/bin/mtouch -sdkroot "/Applications/Xcode5-DP.app/Contents/Developer" --cache "/Users/XXX/WS/YYY/Application/iOS/obj/iPhone/Debug/mtouch-cache" --nomanifest --nosign -dev "/Users/XXX/WS/YYY/Application/iOS/bin/iPhone/Debug/iOS.app" -r "/Users/XXX/WS/PTCommon/bin/Debug/PTCommon.iOS.dll" -r "/Developer/MonoTouch/usr/lib/mono/2.1/System.dll" -r "/Developer/MonoTouch/usr/lib/mono/2.1/System.Xml.dll" -r "/Developer/MonoTouch/usr/lib/mono/2.1/System.Core.dll" -r "/Developer/MonoTouch/usr/lib/mono/2.1/monotouch.dll" -r "/Developer/MonoTouch/usr/lib/mono/2.1/OpenTK-1.0.dll" -debug -nolink -sdk "7.0" -targetver "4.3" --sgen --new-refcount --abi=armv7,armv7s "-compiler:clang" "/Users/XXX/WS/YYY/Application/iOS/bin/iPhone/Debug/iOS.exe"
AOT Compilation exited with code 134, command:
MONO_PATH=/Users/XXX/WS/YYY/Application/iOS/bin/iPhone/Debug/iOS.app /Developer/MonoTouch/usr/bin/arm-darwin-mono-sgen --debug -O=gsharedvt --aot=mtriple=armv7-ios,full,static,asmonly,direct-icalls,dwarfdebug,no-direct-calls,iphone-abi,outfile=/var/folders/__/rbtxrnc93cxc_hvdsf74rtrr0000gn/T/tmp274d87f8.tmp/monotouch.dll.armv7.s "/Users/XXX/WS/YYY/Application/iOS/bin/iPhone/Debug/iOS.app/monotouch.dll"
* Assertion at ../../../../../mono/mono/metadata/metadata.c:3409, condition `ptr' not met
Mono Ahead of Time compiler - compiling assembly /Users/XXX/WS/YYY/Application/iOS/bin/iPhone/Debug/iOS.app/monotouch.dll
error MT3001: Could not AOT the assembly '/Developer/MonoTouch/usr/lib/mono/2.1/monotouch.dll'
Release builds for the same solution/project do not exhibit the behavior.
A minimal app does not demonstrate the behavior---I will attempt to find a repro case that I can attach to the report.
Xamarin Studio 4.1.4 with Xamarin.iOS 22.214.171.124.
You can easily fix this by changing your application Deployment Target to 3.1 (or later, as required by your application).
The default (3.0) does not work when using the new Apple provider compiler (clang). This is a known issue and the next version will set the default value to 3.1 to avoid this.
I checked and my deployment target was set to 4.3.
I bumped it up to 7.0 and issued a clean build, no change in outcome.
Anything else I can do to extract more info for you?
Thanks for the quick response.
Uho, sorry, that was a different issue. This one is caused by the use of "Dont link"  on your project.
This will be fixed in the next alpha release. Right now the workaround is to let the default "Link SDK" option on your project.
Note that you should not disable the linker as it will make your application a lot bigger , slower to build and disable quite a few optimizations for your application .
 `-nolink` on your command line
 Apple has a size limit for native executables
 See my Evolve presentation on Advanced Build Mecanics for more details @ http://xamarin.com/evolve/2013
Yep, now that worked. Thanks.
Note that the default setting "Link SDK assemblies only" flags a warning at the right of the drop-down: "Enabling this feature may hinder debugging....," which was likely what prompted me to back it off to the don't-link state (the IDE then reverts from warning to a normal info mouse-over state). This is probably worth making a bit more clear --- or, if it's an illegal combination it should not be selectable.
(What should we be looking for in debugging degradation per the warning, anyway?)
The linker's job is to remove unused code. E.g. it can remove a property getter that is not used anywhere. OTOH you could find it useful while debugging (as a watch) to expose the state of an object.
So it *may* hinder debugging but, without it, it *does* hinder debugging too (requiring a lot more time to build and deploy to devices).