This is Xamarin's bug tracking system. For product support, please use the support links listed in your Xamarin Account.
Bug 52241 - WatchOS extension native linking fails when LLVM used
Summary: WatchOS extension native linking fails when LLVM used
Status: VERIFIED FIXED
Alias: None
Product: iOS
Classification: Xamarin
Component: General (show other bugs)
Version: XI 10.4 (C9)
Hardware: PC Mac OS
: --- normal
Target Milestone: (C9)
Assignee: Rolf Bjarne Kvinge [MSFT]
URL:
Depends on:
Blocks:
 
Reported: 2017-02-02 05:13 UTC by t9mike
Modified: 2017-02-08 12:02 UTC (History)
7 users (show)

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


Attachments
Build Output (394.06 KB, text/plain)
2017-02-02 05:14 UTC, t9mike
Details

Description t9mike 2017-02-02 05:13:34 UTC
My watch extension won't compile w/ LLVM enabled. I believe I need this to embed bitcode, as iTunes Connect rejects app without (only issue!). I test fine in Ad Hoc compile mode on device with LLVM disabled.

Error is:

/Users/mmuegel/Mike/Git/Main2/Projects/SundialWatchApp/App/WatchExtension/WatchAppExtension.csproj (Build) ->
/Library/Frameworks/Mono.framework/External/xbuild/Xamarin/iOS/Xamarin.iOS.Common.targets (_CompileToNative target) ->

	MTOUCH: error MT5210: Native linking failed, undefined symbol: ___sync_lock_test_and_set_4. Please verify that all the necessary frameworks have been referenced and native libraries are properly linked in.
	MTOUCH: error MT5210: Native linking failed, undefined symbol: ___sync_fetch_and_add_4. Please verify that all the necessary frameworks have been referenced and native libraries are properly linked in.
	MTOUCH: error MT5210: Native linking failed, undefined symbol: ___sync_synchronize. Please verify that all the necessary frameworks have been referenced and native libraries are properly linked in.
	MTOUCH: error MT5210: Native linking failed, undefined symbol: ___sync_val_compare_and_swap_4. Please verify that all the necessary frameworks have been referenced and native libraries are properly linked in.
	MTOUCH: error MT5202: Native linking failed. Please review the build log.

	 0 Warning(s)
	 5 Error(s)

Full build log attached.

=== Xamarin Studio Business ===

Version 6.2 (build 1798)
Installation UUID: 2ef48581-52bf-43ad-b554-cca1ec408cf4
Runtime:
	Mono 4.8.0 (mono-4.8.0-branch/084f912) (64-bit)
	GTK+ 2.24.23 (Raleigh theme)

	Package version: 408000478

=== NuGet ===

Version: 3.5.0.0

=== Xamarin.Profiler ===

'/Applications/Xamarin Profiler.app' not found

=== Apple Developer Tools ===

Xcode 8.2.1 (11766.1)
Build 8C1002

=== Xamarin.iOS ===

Version: 10.4.0.97 (Xamarin Business)
Hash: 2bcf787
Branch: cycle9
Build date: 2017-01-25 12:40:52-0500

=== Xamarin.Android ===

Version: 7.1.0.30 (Xamarin Business)
Android SDK: Not found

=== Xamarin Android Player ===

Version: 0.1.1
Location: /Applications/Xamarin Android Player.app

=== Xamarin.Mac ===

Not Installed

=== Xamarin Inspector ===

Not Installed

=== Build Information ===

Release ID: 602001798
Git revision: 79fea1cb975eace20d5316687ebb9ff687b51451
Build date: 2017-01-27 07:34:26-05
Xamarin addins: 8e37b5263f1583e25ed2eda77f84829dfcf42759
Build lane: monodevelop-lion-cycle9

=== Operating System ===

Mac OS X 10.11.6
Darwin MacBook1 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 1 t9mike 2017-02-02 05:14:59 UTC
Created attachment 19690 [details]
Build Output
Comment 2 Rolf Bjarne Kvinge [MSFT] 2017-02-02 07:19:34 UTC
Workaround: open your project file in a text editor, and add this to your AdHoc|iPhone configuration:

    <MtouchEnableBitcode>true</MtouchEnableBitcode>
Comment 3 Rolf Bjarne Kvinge [MSFT] 2017-02-02 07:20:56 UTC
Correction: edit the configuration that fails (AppStore in your case), not the one that works :)
Comment 4 Rolf Bjarne Kvinge [MSFT] 2017-02-02 09:25:09 UTC
@Sebastien, the quick fix for a C9 timeframe would be to automatically enable bitcode in mtouch if llvm is enabled. Does that sound like a plan? A more thorough solution would be to figure out how to support building with LLVM without bitcode (which is partially tracked in bug #52241), but that's more invasive, and would likely require mono+IDE changes as well.
Comment 5 t9mike 2017-02-02 15:04:59 UTC
I see that:

<MtouchEnableBitcode>true</MtouchEnableBitcode>

was was already in Release|iPhone. I enabled LLVM on watch app ext project and manually added above. This fixed my issue, thank you. 

** There should be a checkbox in the Xamarin Studio project editor for this. **

Is there any reason to enable this except for app store builds? Unnecessary extra compute time, no?

Some background on my watch app and feedback on toolchain.

I previously had WatchOS 1.0 solution for my app. When I recently tried converting to watch OS 3.0, I had all sort of problems.

So created new app and watch projects from scratch using the wizards to ensure I got all default project settings and even info.plist and such, and then added back my needed edits.

A major difference I saw with past Xamarin was that Ad Hoc and App Store configurations where no longer added to the project/solution! Why? This is a major deficiency.

You now have "Sign and Distribute" feature of "Archives" that is intended to re-sign the bundles for Ad Hoc or App Store. But this interface is slow: it does not remember previous provisioning profile selections and does not automatically select matching profiles in keychain! It also locks up the GUI for me after use: I have to quit XS after use because the Close button does not work nor the close window X.

Also note: your online docs mixes discussion of the "Sign and Distribute" approach and tried and true separate Ad Hoc and App Store project configurations.

So I went back and created App Store and Ad Hoc configurations. I thought I did a copy of Release and would have gotten the copy of <MtouchEnableBitcode>true</MtouchEnableBitcode>. Perhaps I did not.

IMHO you should nuke "Sign and Distribute" outright. This adds little value to the toolchain and is something else to test and maintain.

This workflow is fine and much more clear/supportable:

- Separate configurations for App Store and Ad Hoc
- "Archive All" to create App Store xarchive
- Remove "Sign and Distribute" option
- Replace with "Open in XCode Archive Tool" and make this the double click action. This can then be used to validation pre-upload, export, upload, etc.

Now I have to see how I can get the size down. Now at 63M app store build, 13M over 50M limit. This with Link All enabled. This evenings project.
Comment 6 Sebastien Pouliot 2017-02-02 16:10:12 UTC
@Rolf yes, I think this makes sense. Double check with Jeff to make sure XS (in C9) will remove the native bits. I'm not trusting my memory this morning (with my cold).

@Vincent could you copy paste Mike's feedback from comment #5 into one (or several) bug reports on the XS addin ?

@Craig, c.c. for the documentation parts.

@Mike, thanks for the feedback. There are reasons for the new workflow. One of them is that the size you see right now (63MB) is not the right size, it's the "working size". It's a long story but Apple made it impossible to have a single, optimal build that works on devices (native code) and includes bitcode (for app store).

The good news is that going thru the new workflow will shrink your application further (about 10MB if this is similar to other projects).
Comment 7 t9mike 2017-02-02 16:21:55 UTC
@Sebastien, I'll mess around with new workflow again tonight.

** https://developer.xamarin.com/guides/ios/watch/deployment/appstore/ doesn't match or mention any of this. **

But why couldn't project (with GUI interface) simply have option for App Store only compile, and templates would enable this for AppStore target? Standard build would pick this up and do magical things. 

AdHoc target would have this "App Store / BitCode Only" option disabled. AppStore target would enabled.
Comment 8 Rolf Bjarne Kvinge [MSFT] 2017-02-02 18:30:50 UTC
master PR: https://github.com/xamarin/xamarin-macios/pull/1620
cycle9 PR: https://github.com/xamarin/xamarin-macios/pull/1621
Comment 9 t9mike 2017-02-02 18:56:59 UTC
I see no change in reported watch app size after using "Sign and Distribute ..." feature of Archives tab to create IPA and then open in Application Loader and it runs its checks.

    The size of watch application 'Sundial.app/Watch/SundialWatchApp.app' (63MB) has exceeded the 50MB size limit."

When I delve into the IPA I see SundialWatchAppExtension is 56.9M uncompressed.

Q: Is there a way to see post-linker versions of assemblies? I.e. do you create copies of original assemblies with unused types/members removed? That will help me focus my optimization.

I will do a Hello World watch app to see what the best case size is. 

Q: What do you find the size of HelloWorldWatchApp.app inside IPA is using your recommended workflow? I want to ensure I can get near that same size on my end.
Comment 10 t9mike 2017-02-03 01:24:42 UTC
My Hello world watch app is 25.7MB on (the watch app inside overall IPA). This with Link All. Please let me know if this is expected.
Comment 11 Rolf Bjarne Kvinge [MSFT] 2017-02-03 06:57:17 UTC
@Mike, yes, unfortunately bitcode is much more verbose than native code (approximately 3x as big), which is why the apps end up being so big. Once Apple has compiled bitcode to native code on their servers, the app size shrinks again. We're working on getting the size down, so this should at least be somewhat improved in the future.
Comment 13 Danish Akhtar 2017-02-08 12:02:14 UTC
Reproduce Status:
I am able to reproduce this issue with X.iOS 10.4.0.97 and observed that I am getting build error mentioned in Bug description, when build watch kit extension with Enable LLVM option in Adhoc mode.

Verified Status:
I have checked this issue with latest C9 X.iOS 10.4.0.119 and with master X.iOS 10.5.0.435 and observed that now this issue is not exists because now Bitcode has been enabled automatically because this version of Xamarin.iOS does not support building watchOS projects using LLVM without enabling bitcode.

Screencast with C9: https://www.screencast.com/t/O0FxZIaRXIg
Screencast with master: https://www.screencast.com/t/jmzR2G1f4J

Hence closing this issue.

Thanks!

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