# Steps to reproduce
Within visual studio (or using msbuild cli)
Compile the xamarin ios project of xamarin form solution with any iPhone configuration (simulator is ok).
linker in all configurations (skipping most of my project assemblies when linkall)
# Expected behavior
The project compiles
# Actual behavior
compilation error with the following:
11> clang: error: unable to execute command: Segmentation fault: 11
11> clang: error: linker command failed due to signal (use -v to see invocation)
11>C:\Program Files (x86)\MSBuild\Xamarin\iOS\Xamarin.iOS.Common.targets(673,3): error : Native linking error: clang: error: unable to execute command: Segmentation fault: 11
11>C:\Program Files (x86)\MSBuild\Xamarin\iOS\Xamarin.iOS.Common.targets(673,3): error : Native linking error: clang: error: linker command failed due to signal (use -v to see invocation)
11>C:\Program Files (x86)\MSBuild\Xamarin\iOS\Xamarin.iOS.Common.targets(673,3): error : Native linking failed. Please review the build log.
# Supplemental info (logs, images, videos)
# Test environment (full version information)
Latest Cycle 7 at the time of writing:
Xamarin.iOS OSX 9.8.1
Xamarin.iOS Windows 4.1.1
Visual Studio 14.0.25123.00 Update 2
a while back, we came across the compile time issue 'clang: error: unable to execute command: Segmentation fault: 11' that made debugging on ios device impossible: https://bugzilla.xamarin.com/show_bug.cgi?id=25303
It was all fine, until we tried Cycle7 a few weeks ago, but now the compile error is not limited to Debug configuration, but also to release.
I see that you are using third-party libraries that reference Xamarin.Forms. Have you updated all of those libraries when you updated Xamarin.Forms to 2.3.1-pre? Do you still get this error if you do not reference those libraries?
Please see if you are able to reproduce this error with a clean Xamarin.Forms project.
Xamarin Forms Team
Yes, I updated all those libraries.
It appears that the Library Postsharp is the culprit, although it always allowed me to Deploy an iphone ipa until cycle 7. Cycle 6 on ipPhone Debug causes the same issue;
Staring from a fresh project does not causes any problems, but our project does, and that is a pretty massive project.
In any case, something changed from cycle 6 to cycle 7 that causes the inability to deploy ipa with our current setup, with postsharp enabled.
So i am looking into it with postsharp, but any info or help your end would be immensely appreciated.
The deployment location of the .ipa package changed in Cycle 7 for Xamarin.iOS. You can find details about that here: https://developer.xamarin.com/releases/ios/xamarin.ios_9/xamarin.ios_9.8/#Bug_Fixes
Marking as resolved answered for now, but please let us know if we can be of further assistance. Thank you!
@Samantha, Please reopen,that has nothing much to do with the location of ipa;
There is a regression from cycle 6+ to cycle 7, as deploying works on 6 and not on 7;
A library we are using, PostSharp, is a part of where it breaks, but it does break due to a regression on the xamarin sdk;
This is causing a pretty big blocker as we are no longer able to debug on devices no matter what, and are unable to update to cycle 7 as our app won't deploy to device.
It looks like the native linker (from Apple's toolchain) is crashing.
Can you try and see if it works if you compile the project using Xamarin Studio on a Mac (my guess is that it will still fail though)?
If that doesn't work, please attach the complete build log.
As postsharp is a Windows code weaving process fired by a msbuild task, it only triggers on windows, so yes, compilation works on MAC, but acts as having the postsharp task disabled. As a result, the postsharp aspects (code attached to methods via marker attributes that will tell the postsharp process to weave the related code there, in the same way mono.cecil works) are not processed.
As per my previous comment, cycle 6 release mode works fine, cycle 7 breaks, with the same postsharp version, and sane Xcode version. So something on the xamarin sdk in cycle 7 broke.
@Ben, can you add "-v -v -v -v" to the additional mtouch arguments in the project's iOS Build, clean & rebuild and then attach the complete build log here?
Postsharp engineers could reproduce the regression and should be in touch with the Xamarin team to share their findings; Or get in touch with them.
See thread there:
attaching the log with "-v -v -v -v" as indicated,
that's Cycle 6 latest version, in Debug|iPhone config (samoe outcome, but release is all ok)
Created attachment 16661 [details]
Cycle6 Débug|iPhone Log
log with "-v -v -v -v" as indicated,
that's Cycle 6 latest version, in Debug|iPhone config (same outcome, but release is all ok)
OK, I'll wait for feedback from the Postsharp engineers then.
Created attachment 16704 [details]
Reproduction of the linking error with PostSharp
You can find the reproduction in the attached LinkingErrorRepro.zip archive.
To reproduce the issue open TestSolution\LinkingErrorRepro.sln in VisualStudio and build TestApp.csproj for iPhone configuration. There's *.mdb file in the lib folder and it seems that removing this file solves the issue.
Unfortunately, we are not able yet to provide you with the source code for the corresponding project that outputs that *.mdb file and library itself. It's tied to our complete testing framework and isolating the code into a smaller project didn't reproduce the issue yet.
Please let us know if there's anything else we can provide to help you with debugging.
Info provided: reopening.
Re-uploading the test case as the csproj was incorrect (mix between Xamarin.iOS Classic and Unified): https://www.dropbox.com/s/lpy03581098r5ru/LinkingErrorRepro.zip?dl=0
I am also able to reproduce the issue, getting build errors when building for debug/device, see: https://gist.github.com/VincentDondain/d415f26756ad50099984af17830c0917
Removing the *.mdb file in the lib folder fixes the build, so it *does* seem to be the root of the issue.
I'm marking the bug as confirmed.
Indeed with C6 builds I'm not getting the same linker error. However I'm getting "MTOUCH: error MT2002: Failed to resolve "System.String System.String::Format(System.IFormatProvider,System.String,System.Object,System.Object)" reference from "mscorlib, Version=220.127.116.11, Culture=neutral, PublicKeyToken=7cec85d7bea7798e"" (likely related to something else)
The error being different, I'm considering the linker issue a regression from cycle6.
>>The error being different, I'm considering the linker issue a regression from cycle6.
Changing the status to High|Critical.
I am not able to duplicate the issue using the latest C8 builds.
> Removing the *.mdb file in the lib folder fixes the build
There was an issue where XVS could produce incorrect .mdb (fixed in C7SR2) that might have been the original problem.
QA: please validate from both the Mac/XS and Windows/VS, thanks!