Compile error: strip exited with code 139
TLDR;
- This is a regression reported in the Xarain repo in October 2023: https://github.com/xamarin/xamarin-macios/issues/19157
- A temporary workaround might be to roll back to
maui-iosworkload 8.0.402 (see comment) - Rolf Kvinge has already found the problem and submitted a PR with a fix but it hasn't yet been merged. It would help for more people to report the problem to Apple, to try to get that prioritised.
Package
Sentry
.NET Flavor
.NET
.NET Version
8.0.8
OS
iOS
SDK Version
4.10.2
Self-Hosted Sentry Version
No response
Steps to Reproduce
- Install Xcode 16 using Xcodes
- Set Xcode 16 active (
sudo xcode-select -s /Applications/Xcode-16.0.0.app/Contents/Developer) - Install .NET 8 tools with Xcode 16 support (see here)
- Create new iOS app (
dotnet new ios) - Add latest Sentry SDK (v4.10.2) from NuGet
-
dotnet publish
Expected Result
The app builds
Actual Result
Error while building:
/usr/local/share/dotnet/packs/Microsoft.iOS.Sdk.net8.0_18.0/18.0.8287-xcode16/tools/msbuild/iOS/Xamarin.Shared.targets(2848,3): error : strip exited with code 139
This issue has been discussed previously here and a PR was created here (but not accepted yet).
For some reason, I was successful building my app successfully yesterday with the same tooling & Sentry version, but not today. It now consistently fails with every test project if I have the Sentry SDK added to, and it succeeds consistently when I remove it.
@tipa do you have your Sentry version pinned? A 4.11.0 release was made a few hours ago.
This is odd though as both the bug and the solution that you linked to seem to be part of a dotnet workload rather than part of Sentry.
The issue also happens for me with 4.11.0. I agree that this totally looks like a problem of dotnet or the Apple tooling - I opened this issue because you perhaps could or would want to workaround the issue since since the it can be reproduced so easily and reliably (at least in my dev environment now, with Xcode 16). Perhaps, as more users .NET users update to Xcode 16, more people could be affected. Are you able to reproduce the problem with the steps I provided?
There are a couple of new issues regarding Cocoa and Xcode 16 as well so I don't expect this to be the last of our problems.
Are you able to reproduce the problem with the steps I provided?
I haven't had a chance to try this yet. I'm a bit nervous about installing XCode 16, at least until we can get all the groundwork in for Sentry working smoothly with net9.0... I'm trying to change as few things as possible, at once.
@jamescrosswell You can install XCode side-by-side with Xcode 15 - I explained the steps in my first post
You like living on the bleeding edge eh @tipa 😜 ?
Thanks for the tip re xcodes.
In this issue it looks like XCode 16 support will come with the net9.0 release in November.
I see in the NSTextList issue that there might be a preview coming in RC2 (~3 weeks away). Once RC2 is available, I'll see if I can reproduce. Even if we can't fix the problem, potentially we can research a workaround.
I'm also seeing this issue is back again with xcode16
I'm also seeing this issue is back again with xcode16
Until dotnet/maui supports XCode 16, I think the only practical workaround is to install Xcode 15.4 also/instead.
The latest MAUI workload requires XCode 16
The latest MAUI workload requires XCode 16
You mean if you target net9.0? We're working on net9.0 support. For MAUI, in particular, it's pretty challenging so it might take a while... hoping to have a pre-release available shortly after Microsoft release net9.0.
We're forced to bump to Xcode 16 in CI now as well: https://github.com/getsentry/sentry-dotnet/pull/3635
Microsoft.iOS 18.0.8303 requires Xcode 16.0 or later. See this run
No even for net8
I ran into this issue yesterday while trying to run a pipeline on devops (about the time that 18.0.8303 was released) got an error telling me to use xcode 16. This gave the code 139 error. Removing sentry from my code allowed the build on iOS. I can still build from Visual Studio but have not figure out how to get the pipeline to use xcode 15.4 and Microsoft.iOS.Sdk 17.5.8030.
We're forced to bump to Xcode 16 in CI now as well: https://github.com/getsentry/sentry-dotnet/pull/3635
Microsoft.iOS 18.0.8303requiresXcode 16.0 or later. See this run
Aha - I see a new net8.0 release has been made to support XCode 16 👍🏻
Tried to update to latest CommunityToolkit.Maiu with requested updated workload then meant switching to Xcode 16, now facing the same "strip exited with code 139" error, which is preventing new builds from being produced for production. Now at a standstill until we can make sense of what is going on. I've tried different settings but continue to get the error. :(
A workaround is to downgrade maui-ios workload by specifying the version:
dotnet workload install maui-ios --version 8.0.402
or if you build MAUI for both iOS and Android:
dotnet workload install maui --version 8.0.402
https://github.com/xamarin/xamarin-macios/issues/19157#issuecomment-2381265987
Thanks @angularsen for providing a workaround!
We're working on resolving this as soon as possible.
Good news is: I cannot reproduce this anymore with the steps provided in the issue description in my local environment. Bad news is: I don't know what changed. Because there are no changes to the SDK that I'm aware of that could have fixed the issue. Is this just all in the dependencies?
I'm finding the issue occurs randomly. I can often build it at few times and sometimes it fails and others it works.
Can someone who is able to reproduce this problem try with version 4.12.0 of the Sentry SDK? That version of the SDK has been compiled and linked using XCode 16...
Can someone who is able to reproduce this problem try with version 4.12.0 of the Sentry SDK? That version of the SDK has been compiled and linked using XCode 16...
@jamescrosswell I can confirm from my side that v4.12.0 doesn't work. I use two packages
<PackageReference Include="Sentry" Version="4.12.0" />
<PackageReference Include="Sentry.Serilog" Version="4.12.0" />
Removing references to sentry fix the issue for me.
Can someone who is able to reproduce this problem try with version 4.12.0 of the Sentry SDK? That version of the SDK has been compiled and linked using XCode 16...
@jamescrosswell I can confirm from my side that v4.12.0 doesn't work. I use two packages
<PackageReference Include="Sentry" Version="4.12.0" /> <PackageReference Include="Sentry.Serilog" Version="4.12.0" />Removing references to sentry fix the issue for me.
To confirm: Are you on Xcode 16 and you updated your dotnet workloads? Please confirm since that seems to work for us. For folks on Xcode 15.4 or earlier, Sentry's SDK 4.11 or lower are required.
We're adding this to the changelog:
If you are using Xcode 16.0, you will need to update the SDK to version
4.12.0or later. If you are still using Xcode 15.4 or earlier, you need to continue to use version4.11.0or earlier.Using Xcode 16 to build .NET applications targeting iOS and Mac Catalyst requires .NET workload for iOS SDK version 18.0.8303. We built the SDK version 4.12.0 using Xcode 16 in order to support this scenario. That, unfortunately, breaks folks using older version of Xcode.
As such, if you are using SDK version
4.12.xand targeting iOS or Mac Catalyst, you will need to install and use Xcode 16 andworkload iOS SDK 18.0.8303Note that .NET 9 will also support Xcode 16, when it is released next month (Nov 2024).
@bruno-garcia Yes, I use Xcode 16.0 and workload iOS SDK 18.0.8303.
It started working the recent couple of days on Azure Pipelines when running
dotnet workload install maui # No longer need to specify --version 8.0.402.1
sudo xcode-select -s /Applications/Xcode_16.app
This installs microsoft.net.sdk.ios version 18.0.8303 and we no longer get strip exit code 139 🎉
If you are running on Azure Pipelines, I assume the VM images were recently upgraded, and maybe it takes time to roll out to all regions.
The problem still persists for me too, with Microsoft.iOS.Sdk.net8.0_18.0/18.0.8303 & Sentry 4.12.0
So, it seems flaky for us when not specifying workload version and it depends on the build agent VM image version in Azure Pipelines. Interestingly, the newer VM image fails, but the 7 day older VM image works.
Working version (Sep 23): macos-14 20240923.101
Image: macos-14 Version: 20240923.101 Included Software: https://github.com/actions/runner-images/blob/macos-14/20240923.101/images/macos/macos-14-Readme.md Image Release: https://github.com/actions/runner-images/releases/tag/macos-14%2F20240923.101
Non-working version (Sep 30): macos-14 20240930.130
Image: macos-14 Version: 20240930.130 Included Software: https://github.com/actions/runner-images/blob/macos-14/20240930.130/images/macos/macos-14-Readme.md Image Release: https://github.com/actions/runner-images/releases/tag/macos-14%2F20240930.130
The only relevant difference I can spot is that .NET Core SDK was bumped from 8.0.401 to 8.0.402.
Update: New version (Oct 7): macos-14 20241007.165 released, not yet sure if it helps
Yesterday a new VM image was released and just popped up in our builds, but I don't see any relevant changes that may improve the situation and it seems you can't request builds with a specific VM image version so I can't easily test if it fixes the problem.
Image: macos-14 Version: 20241007.165 Included Software: https://github.com/actions/runner-images/blob/macos-14/20241007.165/images/macos/macos-14-Readme.md Image Release: https://github.com/actions/runner-images/releases/tag/macos-14%2F20241007.165
So, it seems flaky for us when not specifying workload version and it depends the build agent VM image version in Azure Pipelines. Interestingly, the newer VM image fails, but the 7 day older VM image works.
Working version (Sep 23): macos-14 20240923.101
Image: macos-14 Version: 20240923.101 Included Software: https://github.com/actions/runner-images/blob/macos-14/20240923.101/images/macos/macos-14-Readme.md Image Release: https://github.com/actions/runner-images/releases/tag/macos-14%2F20240923.101
Non-working version (Sep 30): macos-14 20240930.130
Image: macos-14 Version: 20240930.130 Included Software: https://github.com/actions/runner-images/blob/macos-14/20240930.130/images/macos/macos-14-Readme.md Image Release: https://github.com/actions/runner-images/releases/tag/macos-14%2F20240930.130
The only relevant difference I can spot is that .NET Core SDK was bumped from
8.0.401to8.0.402.
I also noticed this. My Azure pipeline was fine with macos-14 / Xcode 16 / iOS SDK 18.0.8303 / Sentry 4.9.0 setup. And just recently starting from 1 October it has started to fail. On my local machine it fails as well.
I managed to randomly queue a build with the brand new VM image version (Oct 7): macos-14 20241007.165
Not sure if this is simply a flaky problem or not, but the newest version built successfully with default worload version:
dotnet workload install maui # No longer need to specify --version 8.0.402.1
sudo xcode-select -s /Applications/Xcode_16.app
Azure Pipelines VM versions:
-
macos-14 20240923.101: OK -
macos-14 20240930.130: strip error code 139 -
macos-14 20241007.165: OK
@angularsen How do you able to use exactly 20241007.165 vmImage version? Did you specifically selected it on azure portal or your yml file?
@AndreyPhilippov No it seems not possible to configure, so I just requeued the build until I got the version I wanted.