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.
When building our iOS project for a device (generic "Device" -- no actual device is plugged in) I get the following error:
MTOUCH: Error MT5209: Native linking error: don't know how to convert instruction ec3ebf88 referencing _mono_monitor_enter_v4_fast to thumb in 'My_Namespace_UIActionThrottler_OnTimer_object_System_EventArgs' from /path/to/obj/iPhone/Debug UITest/mtouch-cache/My.Assembly.exe.armv7.o for architecture armv7 (MT5209) (My.Assembly)
When I change Supported Architectures from "ARMv7 + ARM64" to just "ARM64" the problem goes away. But I need ARMv7 support because I want this build to go to Test Cloud for a number of older devices devices.
I tried to reproduce this with a brand new iOS project and it does not reproduce (even if I copy UIActionThrottler into the new project). I have been unable to determine the underlying cause. Any ideas? This is a new problem; it used to build fine.
Xamarin Studio Community
Version 6.2 (build 1686)
Installation UUID: 2a603873-20f2-4e5d-a22b-d1b5790caa3b
Mono 4.8.0 (mono-4.8.0-branch/df81fe4) (64-bit)
GTK+ 2.24.23 (Raleigh theme)
Package version: 408000395
Apple Developer Tools
Xcode 8.2.1 (11766.1)
Version: 10.4.0.54 (Xamarin Studio Community)
Build date: 2016-12-17 15:04:15-0500
Version: 18.104.22.168 (Xamarin Studio Community)
Android SDK: /Users/ncook/Library/Developer/Xamarin/android-sdk-macosx
Supported Android versions:
4.0.3 (API level 15)
4.4 (API level 19)
5.0 (API level 21)
5.1 (API level 22)
6.0 (API level 23)
7.0 (API level 24)
7.1 (API level 25)
SDK Tools Version: 25.2.3
SDK Platform Tools Version: 25.0.1
SDK Build Tools Version: 24.0.3
Java SDK: /usr
java version "1.8.0_102"
Java(TM) SE Runtime Environment (build 1.8.0_102-b14)
Java HotSpot(TM) 64-Bit Server VM (build 25.102-b14, mixed mode)
Android Designer EPL code available here:
Xamarin Android Player
Version: 22.214.171.1244 (Xamarin Studio Community)
Build date: Tue, 15 Nov 2016 21:13:59 GMT
Release ID: 602001686
Git revision: 3e8b559b32962db4d3860072ce79dee44f0c6a88
Build date: 2016-12-15 09:09:49-05
Xamarin addins: d83d393881f04cf1f62093120f1ed619e3a13c5b
Build lane: monodevelop-lion-cycle9
Mac OS X 10.11.6
Darwin Nates-MBP.lan 15.6.0 Darwin Kernel Version 15.6.0
Wed Nov 2 20:30:56 PDT 2016
Enabled user installed addins
Addin Maker 1.3.2
This is most likely an issue with the size of the app (see bug #1102): for 32-bit architectures (armv7 and armv7s) the Mach-O file format has size restrictions for object files, and if the size is too big, you may end up with strange linker errors like these.
What's the size of the My.Assembly.exe.armv7.o and My.Assembly.exe.armv7.s files?
The armv7.o file is 40.1 MB and the armv7.s file is 137 MB.
Interestingly, I just found something else that "works", in terms of getting it to compile without that error. We have an iOS extension project that we exclude from UITest builds by unloading it. The reason we are excluding the iOS extension project is because it is a workaround for the following bug:
As suggested by Glenn Wilson of the UITest team in the below forum post, we unload the iOS extension project to workaround the UITest issue.
If I reload the iOS extension project, the app builds for "ARMv7 + ARM64" without error. But as expected, I then run into bug #48276 again. According to Glenn Wilson in the forum post above, there is no ETA for resolution of 48276.
Stepping back for a minute, it's not clear to me how the two issues are related. Why would ARMv7 make a difference in the case of an iOS extension being excluded? Seems like a bug in the toolchain.
@Nate, can you try adding the following to the additional mtouch arguments in the main project's iOS Build options:
When building with an extension, we'll automatically put the Mono runtime in the app as a framework, so that it can be used by both the main app and the extension (this is a space-saving measure, otherwise the mono runtime would have had to be linked statically into both the extension and the main app, thus duplicating a lot of code unnecessarily).
If this doesn't work, could you attach a build log of both the working build (with the extension disabled), and the non-working build (with the extension included), so that I can see what else differs between those builds?
@Rolf Adding <MtouchExtraArgs>--mono:framework</MtouchExtraArgs> indeed works around the problem; the build succeeds. Can you help me understand a bit better why that works? Is it because, by using that option to save space, bug #1102 is avoided?
@Nate, unfortunately I don't really understand why that works. My _guess_ is that it it's somehow related to the fact that the main executable is smaller now (because the Mono runtime is in a framework, and not linked into the native executable as it usually would be), but it's nothing more than a guess.
The space savings (considering the entire app, not just the executable) only come if more than one executable needs the mono runtime (this is why we only enable the --mono:framework option by default for apps with extensions, since in that case there are at least 2 executables that need the mono runtime), for apps without extensions there is a slight space increase.
I'm going to close this as a duplicate of bug #1102; if you want us to have a deeper look at your particular app and see if we can reduce the size of the native code we generate, please attach a complete solution we can use to reproduce the problem (and reopen this bug) - but unless we find some strange degenerate case in your app that we can easily fix, it will take a while for us to investigate your app (and we may also find that there's not much we can do).
*** This bug has been marked as a duplicate of bug 1102 ***
Hi! Can you please provide some details about this size limitation? I did a quick search about Mach-O file format and I failed to find any documentation which mentions this size limit. I need it for my work.
@Levente, it's been a few years since I looked at it, but IIRC it is something like this: the Mach-O object file has a section with code locations that the linker need to fix during linking, but the valid range for these code locations is too small (IIRC there can be branch instructions whose offset is outside that range).