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.
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.
/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.
Full build log attached.
=== Xamarin Studio Business ===
Version 6.2 (build 1798)
Installation UUID: 2ef48581-52bf-43ad-b554-cca1ec408cf4
Mono 4.8.0 (mono-4.8.0-branch/084f912) (64-bit)
GTK+ 2.24.23 (Raleigh theme)
Package version: 408000478
=== NuGet ===
=== Xamarin.Profiler ===
'/Applications/Xamarin Profiler.app' not found
=== Apple Developer Tools ===
Xcode 8.2.1 (11766.1)
=== Xamarin.iOS ===
Version: 10.4.0.97 (Xamarin Business)
Build date: 2017-01-25 12:40:52-0500
=== Xamarin.Android ===
Version: 18.104.22.168 (Xamarin Business)
Android SDK: Not found
=== Xamarin Android Player ===
Location: /Applications/Xamarin Android Player.app
=== Xamarin.Mac ===
=== Xamarin Inspector ===
=== 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
Created attachment 19690 [details]
Workaround: open your project file in a text editor, and add this to your AdHoc|iPhone configuration:
Correction: edit the configuration that fails (AppStore in your case), not the one that works :)
@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.
I see that:
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.
@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).
@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.
master PR: https://github.com/xamarin/xamarin-macios/pull/1620
cycle9 PR: https://github.com/xamarin/xamarin-macios/pull/1621
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.
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.
@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.
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.
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.