Bug 45380 - Cant compile/link library for deployment to appstore ONLY on ARMv7 and ARMv7s..
Summary: Cant compile/link library for deployment to appstore ONLY on ARMv7 and ARMv7s..
Alias: None
Product: iOS
Classification: Xamarin
Component: General ()
Version: XI 10.0 (iOS10)
Hardware: PC Windows
: --- normal
Target Milestone: Untriaged
Assignee: Bugzilla
Depends on:
Reported: 2016-10-13 19:11 UTC by Brad Chase
Modified: 2017-02-07 18:48 UTC (History)
6 users (show)

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

Notice (2018-05-24): bugzilla.xamarin.com is now in read-only mode.

Please join us on Visual Studio Developer Community and in the Xamarin and 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 Links.

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 for Bug 45380 on Developer Community or GitHub if you have new information to add and do not yet see a matching new report.

If the latest results still closely match this report, you can use the original description:

  • Export the original title and description: Developer Community HTML or GitHub Markdown
  • Copy the title and description into the new report. Adjust them to be up-to-date if needed.
  • Add your new information.

In special cases on GitHub you might also want the comments: GitHub Markdown with public comments

Related Links:

Description Brad Chase 2016-10-13 19:11:50 UTC
We can only compile/deploy for ARM64.  ARMv7 and ARMv7s both dont work.  We can debug just fine, we just cant deploy from what it seems.

clang: error: linker command failed with exit code 1 (use -v to see invocation)
1>C:\Program Files (x86)\MSBuild\Xamarin\iOS\Xamarin.iOS.Common.targets(700,3): error : Native linking error: no pc-rel bx arm instruction. Can't fix up branch to _ves_icall_System_Math_Floor in Shared_Common_Files_AppFileUploadInfo_GenerateKey in 'Shared_Common_Files_AppFileUploadInfo_GenerateKey' from /Users/user/Library/Caches/Xamarin/mtbs/builds/App.iOS/af6f91cefc4c60e12be13a02f6072906/obj/iPhone/AppStore/mtouch-cache/Avmosys.Library.exe.armv7.o for architecture armv7
1>C:\Program Files (x86)\MSBuild\Xamarin\iOS\Xamarin.iOS.Common.targets(700,3): warning : References to 'sqlite3' might require additional -framework=XXX or -lXXX instructions to the native linker
1>C:\Program Files (x86)\MSBuild\Xamarin\iOS\Xamarin.iOS.Common.targets(700,3): error : Native linking failed. Please review the build log.

That is the error, when we comment out that code, it just goes to the next spot.  I dont think it has much to do with the code.  The spot this particular one is failing on is a simple Math.Floor call.

Since you have access to our solution, to repro all you have to do is put the solution in AppStore or Ad-Hoc and try to build it.  It will error with that problem.  We REALLY need this fixed or a workaround asap as we cannot deploy to store or test on our devices currently.
Comment 1 Zoltan Varga 2016-10-13 19:37:15 UTC
These kinds of errors usually happen when the app is too big and the generated native code is bigger than some system limit. Changing the linker setting to 'Link Framework SDKs only' or 'Link All' might fix the issue. Also, turning on llvm ('Use the LLVM optimizing compiler' option) will lead to smaller executables which might also fix the issue.
Comment 2 Brad Chase 2016-10-13 19:42:38 UTC
We already link using SDK assemblies and this happens with and without llvm.  Link all doesn't work for us because it culls out code we actually need.  Why would it work on arm64 but not the others?  How can we extend the system limit?
Comment 3 Sebastien Pouliot 2016-10-13 20:32:17 UTC
> Since you have access to our solution

@Brad we do not share customer data/code across teams. If you can tell us who has access then we can get in touch with them (and you on c.c.) to see if it can be shared with engineering team. You can mark your reply as private.
Comment 4 Brad Chase 2016-10-13 20:44:27 UTC
I do not know how to make it private unfortunately but Brendan Zagaeski & Rodrigo Moya Piernavieja have access currently to our source.  If you need more info I can email you my personal info and move things along.
Comment 5 Sebastien Pouliot 2016-10-13 20:50:32 UTC
c.c. both

@Brad, you can make a comment private by checking the checkbox just above the comment text box

> Additional Comments: [ ] Make comment private (visible only to the reporter and members of the Xamarin Team group)
Comment 6 Brendan Zagaeski (Xamarin Team, assistant) 2016-10-13 20:55:19 UTC
@Sebastien, actually I found out last night that something's broken with the Bugzilla privacy checkboxes for non-Xamarin users at the moment.  They do not appear for me anymore on my non-Xamarin test account, even when that account is the reporter of the bug.  The only way for users to get some form of privacy at the moment is to set the Xamarin Team group when _filing_ the bug.  I am planning to follow-up today with the folks who were updating Xamarin's Bugzilla settings that I think caused this breakage.
Comment 9 Brad Chase 2016-10-14 19:42:43 UTC
AvmosysX, and dev branch is just fine.  btw I was able to get it to compile using the Link All Assemblies with an exception for CSLA.  That said it still wont run on the devices except ARM64.  I get kAMDIncorrectArchitectureError in the log file.

Do you need more info zoltan?  If so email me at brad.chase@argus.aero.
Comment 10 Zoltan Varga 2016-10-14 20:37:24 UTC
I managed to compile the app by enabling llvm. It looks like the problem is that the app is simply too big. The .exe file contains 9000 classes and over 100k methods, the native code for it is over 134mb. With llvm enabled, this goes down to 50mb, but I'm not sure that is enough to go below
the apple imposed limits:


Even if apple would allow bigger files, the underlying operating system and file formats have limits which causes the linker error above. This differs between architectures, this is why arm64 works, and armv7 doesn't.
Comment 11 Brad Chase 2016-10-14 20:49:44 UTC
Yea LLVM works taking down to size and runs on the arm64 just fine in test flight.  Problem is turning LLVM on for armv7 and armv7s still wont link.  Hmm, so i guess no way around this without limiting classes?  We have them in there now because in the future we plan on having those views built that are from our older product.
Comment 12 Zoltan Varga 2016-10-14 21:04:07 UTC
I think the best solution is limiting classes, having code compiled in which is not used is going to increase app size, increase compilation times, etc.
Comment 13 Brad Chase 2016-10-24 13:52:24 UTC
ok so I knocked out a bunch of classes... Unfortunately we needed the majority of them.  I got everything to compile for Ad-Hoc using specific libraries for each shared library for each platform.  With all the bells and whistles for compiling and linking it works well.  So we no longer have the issue *currently*, we will as we grow I imagine.  Hopefully Arm7-7s support dies out by that time.  Question remains, where does this problem lie, with apple or with Xamarin?  And what exactly is the problem.  I would like a more indepth answer to the problem.  Thanks.
Comment 14 Brad Chase 2016-10-24 14:33:48 UTC
Also to add to my last comment, the size might be large for debugging, but after linking the size fits just fine on the device and the app store.  Is there a way to debug on ARM7?
Comment 15 Zoltan Varga 2016-10-24 16:13:22 UTC
The way xamarin.ios works currently is that each .net assembly is compiled to one ios object file. If the assembly is very big, the resulting object files/executable files might become too large, either going over some system limit, or exposing problems in apples compiler/linker. The result is strange linker errors like this.
Comment 16 Brad Chase 2016-10-24 23:19:01 UTC
Ahh I see. So maybe two options would be to either compile down for the target device, separate them, or in the meantime give a graceful exit for those who don't know what current output is?  I know how to get around it now but I'm sure others don't.  Either way thanks for the help in getting around it!
Comment 17 Zoltan Varga 2016-10-25 03:59:57 UTC
We could error out if the executable code is too big, but don't really know the exact limit which is too big.
Comment 18 Vincent Dondain [MSFT] 2016-12-07 14:59:46 UTC
Marking this bug as confirmed as it seems all the required information has been provided and we'll likely try to error out if the executable code is too big.
Comment 19 Rodrigo Kumpera 2017-02-07 18:48:48 UTC
This is not a bug, but a platform limitation.

Returning to the XI team as tooling can be improved here.