Runtime: Running dotnet core on Alpine for ARM32

[JensNordenbro]

Due to its small footprint (OS image size), Alpine is suited for embedded scenarios on ARM32.

Things leading to this:

• Today dotnet core is supported on ARM32.
• Today dotnet core 2.1 is running on Alpine for x86.
• Today dotnet core 3.1 is running on Alpine for ARM64.

It is expected to have symmetry in OS support between different CPU architectures where possible.

(If/when this is implemented the docker images for running .net core application should be available. )

This is a fork of https://github.com/dotnet/coreclr/issues/17468

[ericstj]

Current support matrix https://github.com/dotnet/core/blob/master/release-notes/3.1/3.1-supported-os.md#linux

It seems this is a request to add Alpine ARM32 to this. @leecow / @jeffschwMSFT do you know if this is something that's been considered? Are there any technical blockers? /cc @wfurt

Marking as 5.0 to answer the question.

[janvorli]

@ericstj There are no technical blockers. It is just about wiring it to our build lab / docker containers (whcih includes rootfs creation). Maybe RID graph, I'm not sure whether we already have it covered or not. Otherwise I believe it should just work.

[JensNordenbro]

Alsö @ericstj ; work was done on 17468 in the old repo.

[ericstj]

Alpine is only x64 in rid graph: https://github.com/dotnet/runtime/blob/129ee5252757ec8bdfccf9b271ded36675570309/src/libraries/pkg/Microsoft.NETCore.Platforms/runtimeGroups.props#L16-L20

Seems like that's not even consistent with the matrix.

[janvorli]

That's strange as we've supported Alpine on ARM64 since 3.0 (see https://hub.docker.com/_/microsoft-dotnet-core-runtime-deps/, the Linux arm64 tags)

[ericstj]

Alsö @ericstj ; work was done on 17468 in the old repo.

Looks to be https://github.com/dotnet/runtime/issues/10111 in new repo.

[ericstj]

That's strange as we've supported Alpine on ARM64 since 3.0 (see https://hub.docker.com/_/microsoft-dotnet-core-runtime-deps/, the Linux arm64 tags)

Looking at the product assets I see it was treated as linux-musl-arm64 so that works from shared-fx but would fail for folks trying to resolve from alpine.ver-arm64 in a self-contained publish.

[hamish-milne]

Is it possible to get a build of this working at present, perhaps using the instructions here https://github.com/dotnet/runtime/issues/10111#issuecomment-384370445 ? I've tried publishing a simple app with the linux-musl-arm RID, which works, but execution fails with Illegal instruction at __stack_chk_fail (some incompatibility with alpine's stack-protection-by-default?)

Happy to help out with this as it's very relevant to my interests :)

[hamish-milne]

Just did another experiment:
From readelf -d on the linux-musl-arm binary:

 0x00000001 (NEEDED)                     Shared library: [libpthread.so.0]
 0x00000001 (NEEDED)                     Shared library: [libdl.so.2]
 0x00000001 (NEEDED)                     Shared library: [libstdc++.so.6]
 0x00000001 (NEEDED)                     Shared library: [libm.so.6]
 0x00000001 (NEEDED)                     Shared library: [libgcc_s.so.1]
 0x00000001 (NEEDED)                     Shared library: [libc.so.6]
 0x00000001 (NEEDED)                     Shared library: [ld-linux-armhf.so.3]

And on the linux-musl-arm64 binary:

 0x0000000000000001 (NEEDED)             Shared library: [libstdc++.so.6]
 0x0000000000000001 (NEEDED)             Shared library: [libgcc_s.so.1]
 0x0000000000000001 (NEEDED)             Shared library: [libc.musl-aarch64.so.1]

So.. looks like the musl-arm RID is in fact compiling with glibc.

[janvorli]

We don't publish packages for linux-musl-arm yet, only linux-musl-arm64. So on arm, we seem to be falling back to linux-arm which is glibc.

[hamish-milne]

Ah I see - makes sense I suppose!

Anything I can do to ameliorate this issue? :) I'm using ghost's instructions to compile coreclr but perhaps things have moved on since then?

[ericstj]

@akoeplinger needed to add arm64 to RID graph. Perhaps we should add arm as well? I think if you do that and build for arm it should work.

[danmosemsft]

@richlander are you tracking this issue? Do you see work here that is must have to ship a successful 5.0?

[danmosemsft]

@dleeapho do you have context on why we don't have Alpine ARM images? (32 bit)

cc @richlander

[janvorli]

After chatting with @richlander last week, I have started to look into enabling official Alpine ARM builds. I have changes in the runtime, dotnet-buildtools-prereqs-docker and sdk repos prepared locally, I am currently waiting for a fix that I've made to arcade few days ago to propagate so that I can continue working on it. It seems it should be quite straightforward.

[danmosemsft]

Oh, that's good news. Thanks @janvorli !

[dleeapho]

@MichaelSimons @mthalman heads up on adding Alpine ARM32 dotnet-docker images once @janvorli is done.

[richlander]

Yes, @janvorli talked to me. This is not required for 5.0. It's a nice-to-have based on the hope of a low cost profile for the work. We also don't expect many users of this.

In my mind, the real reason to do this isn't to enable support for Alpine ARM32 but that we'd now have Alpine support for all supported container configurations. This would enable us to create manifest tags for Alpine images, which would then make it easier for us to provide better UX for Alpine. So, in doing this work for ARM32, we can improve the experience for x64 and ARM64 (similar to what exists for Debian already). Apple Silicon devices make this more relevant.

[joperezr]

Pushing the milestone to 6.0 given @richlander comment above. We might still get it in for 5.0 but won't be tracked as a must-have.

[JensNordenbro]

I just would like to add as the creator of this item that there is much more to this than just symmetry amongst your rids. This is also about embedded support and the fact that all docker images for serious production use tend to gravitate towards Alpine. Basically this will make .NET attractive on a new market!

[janvorli]

Update: I've merged in all necessary changes to the runtime repo, so nuget packages should be available soon.
The next step is to enable producing runtime / sdk packages.

[mthalman]

@janvorli - Do you have an estimate of when this will be ready? Will it be in RC2?

[janvorli]

@mthalman not in RC2, as the window got closed. I will try to request accepting port of the change to the GA though.