Bug 27744 - Using an F# iOS test app fails with AOT error
Summary: Using an F# iOS test app fails with AOT error
Status: CONFIRMED
Alias: None
Product: iOS
Classification: Xamarin
Component: General (show other bugs)
Version: master
Hardware: PC Mac OS
: Normal normal
Target Milestone: Untriaged
Assignee: Zoltan Varga
URL:
Depends on:
Blocks:
 
Reported: 2015-03-06 17:57 UTC by Cody Beyer (MSFT)
Modified: 2015-05-12 16:22 UTC (History)
5 users (show)

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


Attachments

Description Cody Beyer (MSFT) 2015-03-06 17:57:26 UTC
### Description 

The linked app uses F# and will build and deploy without issue in Visual Studio with a Mac Build Host. However when building directly on a Mac with XS, it fails with an AOT error.

### App and Build Logs

https://www.dropbox.com/s/th0kpnfua29iobd/LogsAndProject.zip?dl=0

### Steps to Reproduce

1. Download, Uncompress and Open linked project
2. Ensure FsReact.iOS.UI.Tests is set as startup project
3. Attempt to deploy to iPhoneSimulator 

### Expected Results

The app should run as it does in VS

### Actual Results

Fails with AOT error similar to listed in the logs from the linked zip

### Version

=== Xamarin Studio ===

Version 5.8 (build 431)
Installation UUID: fe050df7-44bb-4337-87ab-a8e27643bb7d
Runtime:
	Mono 3.12.0 ((detached/b8f5055)
	GTK+ 2.24.23 (Raleigh theme)

	Package version: 312000077

=== Apple Developer Tools ===

Xcode 6.1.1 (6611)
Build 6A2008a

=== Xamarin.iOS ===

Version: 8.6.2.26 (Business Edition)
Hash: 9905782
Branch: 
Build date: 2015-02-26 11:05:07-0500

=== Xamarin.Android ===

Version: 4.20.0.28 (Business Edition)
Android SDK: /Users/beyerc/Library/Developer/Xamarin/android-sdk-macosx
	Supported Android versions:
		2.1   (API level 7)
		2.2   (API level 8)
		2.3   (API level 10)
		3.1   (API level 12)
		4.0.3 (API level 15)
		4.2   (API level 17)
		4.4   (API level 19)
		5.0   (API level 21)
Java SDK: /usr
java version "1.7.0_71"
Java(TM) SE Runtime Environment (build 1.7.0_71-b14)
Java HotSpot(TM) 64-Bit Server VM (build 24.71-b01, mixed mode)

=== Xamarin Android Player ===

Version: Unknown version
Location: /Applications/Xamarin Android Player.app

=== Xamarin.Mac ===

Version: 1.10.0.18 (Business Edition)

=== Build Information ===

Release ID: 508000431
Git revision: 5415bcba0b0e3085ccc932aca663e546538b01c9
Build date: 2015-03-01 20:17:45-05
Xamarin addins: f0aa1df37165aaed8c223aa74fba372008f302a7

=== Operating System ===

Mac OS X 10.10.2
Darwin byrc-mbp.router 14.1.0 Darwin Kernel Version 14.1.0
    Mon Dec 22 23:10:38 PST 2014
    root:xnu-2782.10.72~2/RELEASE_X86_64 x86_64
Comment 1 Armin Sander 2015-03-07 05:57:54 UTC
It seems that the root cause of the problem is related to the portable F# class library that is referenced.

When the project "FsReact" is recreated as an F# iOS unified library project, the build works fine in Debug / Release | iPhone configurations (with a minor modification: two printf calls needed to be removed for some unknown reasons).

I also noticed that the Project Options of FsReact show that the target framework (Profile259) is not installed, even though it seems to be available in the directory:

/Library/Frameworks/Mono.framework/Versions/3.12.1/lib/mono/xbuild-frameworks/.NETPortable/v4.5/Profile

This problem shows up as an error when MSBuild is disabled.
Comment 2 Rolf Bjarne Kvinge [MSFT] 2015-03-09 08:11:32 UTC
Can you add "-v -v -v -v" to the additional mtouch arguments and attach the full build log from a build in Visual Studio? Then I can compare with a Xamarin Studio build, and see if I can find the difference.
Comment 4 Armin Sander 2015-03-09 09:14:37 UTC
Thanks Rolf, 

I've attached the mtbserver build log of a build with a Debug | iPhone configuration and "-v -v -v -v" that builds and runs on my iPad.
Comment 5 Rolf Bjarne Kvinge [MSFT] 2015-03-09 10:09:02 UTC
That log shows that the VS build is copying the Facade assemblies from Windows. Since that works, this is likely an issue with our Facade assemblies.

Marek, can you have a look?
Comment 6 Marek Safar 2015-03-13 08:58:23 UTC
Fixed in mono master, commit 777dbc17d5fab2360f5918f4cc76f2bf27df7e2e.

It's now failing with 

* Assertion at dwarfwriter.c:1252, condition `tdie' not met

when dwarfdebug is enable, which looks like debug writer limitation. Reassigning to Zoltan.
Comment 7 Zoltan Varga 2015-03-13 17:55:11 UTC
This looks like a part of the original problem, the string type is encoded as MONO_TYPE_CLASS and not MONO_TYPE_STRING.

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