This is Xamarin's bug tracking system. For product support, please use the support links listed in your Xamarin Account.
Bug 52727 - [iOS cycle9] MT3001 Could not AOT the assembly
Summary: [iOS cycle9] MT3001 Could not AOT the assembly
Status: VERIFIED FIXED
Alias: None
Product: iOS
Classification: Xamarin
Component: Tools (show other bugs)
Version: XI 10.4 (C9)
Hardware: Macintosh Mac OS
: Normal normal
Target Milestone: C9SR0
Assignee: Rolf Bjarne Kvinge
URL:
Depends on:
Blocks:
 
Reported: 2017-02-23 22:46 UTC by Guillaume Perrot
Modified: 2017-03-17 00:08 UTC (History)
7 users (show)

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


Attachments

Description Guillaume Perrot 2017-02-23 22:46:28 UTC
Since the release of Xamarin.iOS 10.4.0.123, Mobile Center SDK users are complaining they cannot build in Debug|iPhone anymore and get /Users/guperrot/projects/MT3001Test/MT3001Test/MTOUCH: Error MT3001: Could not AOT the assembly '/Users/guperrot/projects/MT3001Test/MT3001Test/obj/iPhone/Debug/mtouch-cache/64/Build/Microsoft.Azure.Mobile.Analytics.iOS.Bindings.dll' (MT3001) (MT3001Test)

I created a sample application at https://github.com/guperrot/mobile-center-MT3001 to show the problem, git clone it, load it, restore packages and build for iPhone (not simulator but build for actual devices).

It works when disabling incremental builds but it fails otherwise.

This behavior was not happening in cycle 8.

This bug is critical for Mobile Center SDK as people start complaining on our support center and we don't know how to modify our SDK to prevent that from happening and we have to tell everyone to disable incremental builds.

We tried rebuilding the nuget packages using the updated xamarin components but the issue remains the same.

Just in case, our SDK code is located at https://github.com/Microsoft/mobile-center-sdk-dotnet/tree/0.6.0 and the bug also happens while we work with project references before shipping a nuget packages, problem happens as soon as we upgrade to xamarin cycle 9.
Comment 1 Guillaume Perrot 2017-02-23 22:53:54 UTC
Setup information:

=== Xamarin Studio Community ===

Version 6.2 (build 1821)
Installation UUID: bbf23e87-8675-4e2f-8e88-b891ad156475
Runtime:
	Mono 4.8.0 (mono-4.8.0-branch/e4a3cf3) (64-bit)
	GTK+ 2.24.23 (Raleigh theme)

	Package version: 408000495

=== NuGet ===

Version: 3.5.0.0

=== Xamarin.Profiler ===

'/Applications/Xamarin Profiler.app' not found

=== Xamarin.Android ===

Version: 7.1.0.41 (Xamarin Studio Community)
Android SDK: /Users/guperrot/Library/Android/sdk
	Supported Android versions:
		4.0.3 (API level 15)
		6.0   (API level 23)
		7.0   (API level 24)
		7.1   (API level 25)

SDK Tools Version: 25.2.5
SDK Platform Tools Version: 25.0.3
SDK Build Tools Version: 25.0.2

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 Inspector ===

Not Installed

=== Apple Developer Tools ===

Xcode 8.2.1 (11766.1)
Build 8C1002

=== Xamarin.Mac ===

Version: 3.0.0.393 (Xamarin Studio Community)

=== Xamarin.iOS ===

Version: 10.4.0.123 (Xamarin Studio Community)
Hash: 35d1ccd
Branch: cycle9
Build date: 2017-02-16 17:40:00-0500

=== Build Information ===

Release ID: 602001821
Git revision: d41b6e51f3fa46a1943f2e31a778d28a7c73d069
Build date: 2017-02-17 15:18:19-05
Xamarin addins: 1363a8d943bab7700c93a97474060b6734aa7f94
Build lane: monodevelop-lion-cycle9

=== Operating System ===

Mac OS X 10.11.6
Darwin guperrot-macbook.guest.corp.microsoft.com 15.6.0 Darwin Kernel Version 15.6.0
    Mon Jan  9 23:07:29 PST 2017
    root:xnu-3248.60.11.2.1~1/RELEASE_X86_64 x86_64
Comment 2 Vincent Dondain 2017-02-23 23:12:55 UTC
Hi,

Here's the full error output: https://gist.github.com/VincentDondain/0755265263d830c483f10a92b784f348

I can confirm the build issue with Debug|Device mode (simulator is working fine) and I can also confirm the fact it works with incremental builds **disabled**.

Tested with this environment: https://gist.github.com/VincentDondain/76beff0cfb4bc93fa72d248a61565e48
Comment 3 Sebastien Pouliot 2017-02-23 23:25:01 UTC
> It works when disabling incremental builds but it fails otherwise.

It's not an AOT issue then, the input must be incorrect / stale.
Comment 4 Rolf Bjarne Kvinge 2017-02-24 09:16:15 UTC
The problem is that there are two binding assemblies, and one of the native libraries depend on the other one:

* Microsoft.Azure.Mobile.Analytics.iOS.Bindings.dll binds MobileCenterAnalytics.a, and requires MobileCenter.a
* Microsoft.Azure.Mobile.iOS.Bindings.dll binds MobileCenter.a

When we do incremental builds, we build each assembly to a dynamic library (dylib), and each native library is linked into the dylib for the corresponding assembly. The problem arises because we don't know that there's a dependency between the native libraries in multiple binding assemblies, so we don't compute the correct arguments for the native linker.

In this particular case we can't compute the dependency automatically, because the native dependency is not reflected in the managed assemblies (Microsoft.Azure.Mobile.Analytics.iOS.Bindings.dll does not reference Microsoft.Azure.Mobile.iOS.Bindings.dll), but even if that were the case, it would still not build in the current stable (that's already reported in bug #43689).

A workaround the Mobile Center team can implement is to unify the two binding assemblies into one (and put both static libraries in the same binding assembly). This will work for customers with older versions of Xamarin.iOS as well.

A trivial workaround I can implement for 15.1 would be to automatically disable incremental builds for projects with more than one binding assembly.

We can also add a LinkWithAttribute.SupportsIncrementalBuilds option (which defaults to true). This way binding projects can opt out of incremental builds themselves easily (which is nice because incremental builds + binding libraries is a recurrent problem, every time we fix one issue a new one pops up). This might not be a viable option for MobileCenter, because it would require every customer to upgrade to Xamarin.iOS 10.4.

For the future, once bug #43689 is fixed, we can remove the workaround, and instead communicate that if there are dependencies between native libraries in multiple binding assemblies, then those dependencies must be reflected in the managed assemblies (in this case Microsoft.Azure.Mobile.Analytics.iOS.Bindings.dll must reference Microsoft.Azure.Mobile.iOS.Bindings.dll).

@Sebastien, does that sound good?

BTW the reasons this works with the previous version if Xamarin.iOS are:

* Due to a bug in Xamarin.iOS native libraries would not be linked into the dylibs (we passed the native library to the native linker when linking the dylib, but no symbols were used from the native library, so the native linker didn't link the native library into the dylib - the fix we did was to list all the native symbols used in the binding assembly to the linker, which results in the native linker actually trying to use the native library)
* Due to another bug in Xamarin.iOS, every native library was linked into the main executable as well, which meant that the previous bug (where the native library was *not* linked into the dylib) went unnoticed.
Comment 5 Rolf Bjarne Kvinge 2017-02-24 10:58:50 UTC
PR to automatically disable incremental builds with multiple binding projects: https://github.com/xamarin/xamarin-macios/pull/1765
PR to add LinkWithAttribute.SupportsIncrementalBuilds: https://github.com/xamarin/xamarin-macios/pull/1764
Comment 6 Sebastien Pouliot 2017-02-24 14:29:50 UTC
Updated both PR, the workaround part needs more discussion.
Comment 7 Guillaume Perrot 2017-02-24 18:44:31 UTC
Hi, Mobile Center cannot combine those two binding assemblies, this would defeat the purpose of having a modular SDK. People can integrate either Analytics or Crashes module or both.
Comment 8 Guillaume Perrot 2017-02-24 22:12:02 UTC
(Mobile Center will preemptively address the explicit referencing issue to prepare for a future release including fix for https://bugzilla.xamarin.com/show_bug.cgi?id=43689)
Comment 9 Guillaume Perrot 2017-02-25 03:07:17 UTC
> In this particular case we can't compute the dependency automatically, because the native dependency is not reflected in the managed assemblies (Microsoft.Azure.Mobile.Analytics.iOS.Bindings.dll does not reference Microsoft.Azure.Mobile.iOS.Bindings.dll)

Regarding that comment, it might be another bug, but we actually reference Microsoft.Azure.Mobile.iOS.Bindings.dll in Microsoft.Azure.Mobile.Analytics.iOS.Bindings.dll in our project setup.

Even when I work with project references (to make sure it's not a nuget issue), I get MT5210/MT5211 errors if I don't call any API from the common nuget package and use analytics only in a test app.
Comment 10 Rolf Bjarne Kvinge 2017-02-27 16:35:21 UTC
(In reply to Guillaume Perrot from comment #9)
> > In this particular case we can't compute the dependency automatically, because the native dependency is not reflected in the managed assemblies (Microsoft.Azure.Mobile.Analytics.iOS.Bindings.dll does not reference Microsoft.Azure.Mobile.iOS.Bindings.dll)
> 
> Regarding that comment, it might be another bug, but we actually reference
> Microsoft.Azure.Mobile.iOS.Bindings.dll in
> Microsoft.Azure.Mobile.Analytics.iOS.Bindings.dll in our project setup.

Having a project reference does not mean that the output assembly ends up with a reference to the other referenced project's assembly.

In particular the C# compiler will only add an assembly reference if that other assembly is actually used.

The monodis tool can be used to inspect the assembly references (Reflector can also do it):

rolf@RolfsMacPro.local ~/test/mobile-center-MT3001 > monodis --assemblyref ./packages/Microsoft.Azure.Mobile.0.6.0/lib/Xamarin.iOS10/Microsoft.Azure.Mobile.iOS.Bindings.dll
AssemblyRef Table
1: Version=2.0.5.0
	Name=mscorlib
	Flags=0x00000000
	Public Key:
0x00000000: 7C EC 85 D7 BE A7 79 8E 
2: Version=0.0.0.0
	Name=Xamarin.iOS
	Flags=0x00000000
	Public Key:
0x00000000: 84 E0 4F F9 CF B7 90 65 
3: Version=2.0.5.0
	Name=System
	Flags=0x00000000
	Public Key:
0x00000000: 7C EC 85 D7 BE A7 79 8E 

rolf@RolfsMacPro.local ~/test/mobile-center-MT3001 > monodis --assemblyref ./packages/Microsoft.Azure.Mobile.Analytics.0.6.0/lib/Xamarin.iOS10/Microsoft.Azure.Mobile.Analytics.iOS.Bindings.dll
AssemblyRef Table
1: Version=2.0.5.0
	Name=mscorlib
	Flags=0x00000000
	Public Key:
0x00000000: 7C EC 85 D7 BE A7 79 8E 
2: Version=0.0.0.0
	Name=Xamarin.iOS
	Flags=0x00000000
	Public Key:
0x00000000: 84 E0 4F F9 CF B7 90 65 
3: Version=2.0.5.0
	Name=System
	Flags=0x00000000
	Public Key:
0x00000000: 7C EC 85 D7 BE A7 79 8E 

Both of these assemblies only reference mscorlib.dll, Xamarin.iOS.dll and System.dll.
Comment 11 Rolf Bjarne Kvinge 2017-03-01 06:31:49 UTC
Fixed.

master: https://github.com/xamarin/xamarin-macios/commit/ee5cc41c5401f8b81c2adce42e122593f97709d8

Closing for QA validation for C9SR0.

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