fix: support musl on Linux

[jpnurmi]

TODO:

• Build system
  • Sentry.Native.targets
  • .slnf without Android
• CI
  • build / sentry-native
  • build / .NET
  • Integration test
  • Docker image: ci: Alpine Linux Docker image (musl) #4190

Notes:

• setup-dotnet is musl-compatible 👍
• setup-java installs musl-incompatible binaries 👎
• setup-android installs musl-incompatible prebuilt (Android SDK Build-Tools) binaries 👎

Close: #4127

[jpnurmi]

Hi @jamescrosswell, I finally managed to get linux-musl-x64 to pass the whole CI pipeline, including integration tests. :) The last remaining TODO-item is to make the Docker image available:

• ci: Alpine Linux Docker image (musl) #4190

Is the approach with Sentry-CI-Build-Linux-musl.slnf sensible? I wish we could use NO_MOBILE=true or NO_ANDROID=true with the existing Sentry-CI-Build-Linux.slnf, but it pulls in several projects that fail to build without Android SDK:

• Sentry.Bindings.Android
• Sentry.Samples.Android
• Sentry.Samples.Maui
• AndroidTestApp (Sentry.Android.AssemblyReader.Tests)

[jpnurmi]

Is there any potential downside to checking the runtime identifier instead of the platform reported by msbuild? Are there any relevant cross-build scenarios we should consider?

[bruno-garcia]

hm, I'm not sure. I know that RID can be explicitly set, to make a build that's specific for a platform.
Or not set (it's optinal is what I mean) in which case the build is not platform specific. But I haven't looked at it in details in years. Maybe @Flash0ver has tips/pointers

[bruno-garcia]

Publish the app for a specific runtime identifier using dotnet publish -r .

Looks like a RID is required in order to build for Native AOT (which makes a lot of sense) so this shouldn't be an isssue

[jpnurmi]

For some reason, checking for RID did not work as expected in this context :(

With RID checks:

$ dotnet build Sentry-CI-Build-Linux-musl.slnf -c Release
[...]
$ tree src/Sentry/Platforms/Native/
src/Sentry/Platforms/Native/
├── CFunctions.cs
├── NativeContextWriter.cs
├── NativeScopeObserver.cs
├── Sentry.Native.targets
├── SentryNative.cs
├── SentrySdk.cs
├── buildTransitive
│   └── Sentry.Native.targets
└── windows-config.cmake

Without RID checks:

$ dotnet build Sentry-CI-Build-Linux-musl.slnf -c Release
[...]
$ tree src/Sentry/Platforms/Native/
src/Sentry/Platforms/Native/
├── CFunctions.cs
├── NativeContextWriter.cs
├── NativeScopeObserver.cs
├── Sentry.Native.targets
├── SentryNative.cs
├── SentrySdk.cs
├── buildTransitive
│   └── Sentry.Native.targets
├── sentry-native
│   └── linux-musl-x64
│       └── libsentry-native.a # <==
└── windows-config.cmake

3 directories, 9 files

[Flash0ver]

I wonder if we're fine with the slightly disjoint behavior for local builds between operating systems ... if I read it correctly:

For ordinary builds (dotnet build or simple build via IDE)

• on Windows and macOS we also build the native dependencies, although not necessarily required, when out-of-date, because $(SentryNativeBuildOutputs) will be set
• on Linux we do not build the native dependencies during ordinary builds locally, because$(SentryNativeBuildOutputs) will not be set when the $(RuntimeIdentifier) is empty

However, when building for a specific platform, and in particular AOT, then the $(RuntimeIdentifier) is set and we build the native dependencies also on Linux.

If I understand the Inputs="$(SentryNativeBuildInputs)" Outputs="$(SentryNativeBuildOutputs)" of the _BuildSentryNativeSDK Target correctly.
Actually, I'm not entirely certain: if $(SentryNativeBuildOutputs) is empty ... which it is in the case of an "ordinary" build on Linux when the $(RuntimeIdentifier) is not set, will the _BuildSentryNativeSDK Target below then be invoked or not invoked?

However, my thought here may be totally nit-picky, as when the Native Dependencies are required, they will be built, so we may have a slight build behavior disjoint between Operating Systems, but the runtime locally should be perfectly fine indeed.

---

UPDATE ... oops, I missed your previous comment @jpnurmi ... I believe I described the same behavior
An "ordinary" dotnet build does not set the $(RuntimeIdentifier).
Do we need the native dependency for just a dotnet build? Conversely, do we need the native dependencies only when specifying an RID?

[jpnurmi]

Aha, thanks! So it might just be my misunderstanding. ;) I compared what outputs were present after dotnet build Sentry-CI-Build-Linux(-musl).slnf on Ubuntu vs. Alpine Linux and tried to achieve the same.

On Ubuntu, if I run dotnet workload restore + dotnet build Sentry-CI-Build-Linux.slnf in a clean sentry-dotnet checkout of the main branch, it does seem to build src/Sentry/Platforms/Native/sentry-native/linux-x64/libsentry-native.a.

[bruno-garcia]

Is the approach with Sentry-CI-Build-Linux-musl.slnf sensible? I wish we could use NO_MOBILE=true or NO_ANDROID=true with the existing Sentry-CI-Build-Linux.slnf, but it pulls in several projects that fail to build without Android SDK:

I'd say so, and I copied your approach on #4187 (which won't land anytime soon since it's blocked on sentry-native win-arm64 support but at least will be ready once that lands

[jamescrosswell]

Is the approach with Sentry-CI-Build-Linux-musl.slnf sensible? I wish we could use NO_MOBILE=true or NO_ANDROID=true with the existing Sentry-CI-Build-Linux.slnf, but it pulls in several projects that fail to build without Android SDK:

Yeah I think that makes sense. The names we give to these solutions are maybe what's confusing. Implicitly building musl we're trying to provide better support for SDK users deploying ASP.NET Core apps using docker containers... so no android required.

However Sentry-CI-Build-Linux.slnf is just the base solution for contributors to the Sentry SDK who are running Linux and they could well be building Android apps... so we can't really rip it out of there.

[jamescrosswell]

I'm not sure if it's caused you any issues here but just FYI:

• Conditionally enabling Native support on net8.0 or later is confusing (or maybe broken) #4203