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.
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.
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?
> 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.
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.
@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)
@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.
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 email@example.com.
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.
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.
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.
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.
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?
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.
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!
We could error out if the executable code is too big, but don't really know the exact limit which is too big.
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.
This is not a bug, but a platform limitation.
Returning to the XI team as tooling can be improved here.