Bug 51226 - Native linking error: don't know how to convert instruction
Summary: Native linking error: don't know how to convert instruction
Status: RESOLVED DUPLICATE of bug 1102
Alias: None
Product: iOS
Classification: Xamarin
Component: Xamarin.iOS.dll (show other bugs)
Version: XI 10.4 (C9)
Hardware: Macintosh Mac OS
: --- normal
Target Milestone: Future Cycle (TBD)
Assignee: Bugzilla
URL:
Depends on:
Blocks:
 
Reported: 2017-01-04 23:58 UTC by Nate Cook
Modified: 2017-01-23 13:16 UTC (History)
4 users (show)

See Also:
Tags:
Is this bug a regression?: ---
Last known good build:


Attachments

Description Nate Cook 2017-01-04 23:58:15 UTC
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.

Version Info:

Xamarin Studio Community
Version 6.2 (build 1686)
Installation UUID: 2a603873-20f2-4e5d-a22b-d1b5790caa3b
Runtime:
	Mono 4.8.0 (mono-4.8.0-branch/df81fe4) (64-bit)
	GTK+ 2.24.23 (Raleigh theme)

	Package version: 408000395

NuGet
Version: 3.5.0.0

Xamarin.Profiler
Not Installed

Apple Developer Tools
Xcode 8.2.1 (11766.1)
Build 8C1002

Xamarin.iOS
Version: 10.4.0.54 (Xamarin Studio Community)
Hash: 4d85810
Branch: master
Build date: 2016-12-17 15:04:15-0500

Xamarin.Android
Version: 7.1.0.14 (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:
https://github.com/xamarin/AndroidDesigner.EPL

Xamarin Android Player
Not Installed

Xamarin.Mac
Version: 3.0.0.324 (Xamarin Studio Community)

Xamarin Inspector
Version: 1.0.0.0
Hash: 1f3067d
Branch: master
Build date: Tue, 15 Nov 2016 21:13:59 GMT

Build Information
Release ID: 602001686
Git revision: 3e8b559b32962db4d3860072ce79dee44f0c6a88
Build date: 2016-12-15 09:09:49-05
Xamarin addins: d83d393881f04cf1f62093120f1ed619e3a13c5b
Build lane: monodevelop-lion-cycle9

Operating System
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
    root:xnu-3248.60.11.1.2~2/RELEASE_X86_64 x86_64

Enabled user installed addins
Addin Maker 1.3.2
Manifest.addin 0.0.0.0
Comment 1 Rolf Bjarne Kvinge [MSFT] 2017-01-05 08:22:10 UTC
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?
Comment 2 Nate Cook 2017-01-05 16:48:23 UTC
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: 

https://bugzilla.xamarin.com/show_bug.cgi?id=48276

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.

https://forums.xamarin.com/discussion/comment/243415/#Comment_243415

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.
Comment 3 Rolf Bjarne Kvinge [MSFT] 2017-01-09 11:46:02 UTC
@Nate, can you try adding the following to the additional mtouch arguments in the main project's iOS Build options:

    --mono:framework

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?
Comment 4 Nate Cook 2017-01-10 16:35:49 UTC
@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?
Comment 5 Rolf Bjarne Kvinge [MSFT] 2017-01-10 17:09:08 UTC
@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 ***
Comment 6 Levente Pusok 2017-01-20 08:32:05 UTC
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.
Comment 7 Rolf Bjarne Kvinge [MSFT] 2017-01-20 09:20:00 UTC
@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).
Comment 8 Levente Pusok 2017-01-23 13:16:26 UTC
Thank you!

Note You need to log in before you can comment on or make changes to this bug.