[Alpine Linux] Dotnet6 package #2782
Comments
|
Nice! I am one of the maintainers of .NET on Fedora and I definitely looking forward to more distributions adapting .NET! As far as I am aware, there isn't any linux-musl-x64 Private.Source.Build.Artifacts file, unfortunately. You should be able to generate it manually, hopefully, by downloading the linux-musl-x64 versions of the linux-x64 nupkgs in Private.Source.Build.Artifacts. Something to watch out, though: some of the nupkgs - specially I wrote a quick and dirty script to find/download nuget package versions by name that you might find useful: https://gist.github.com/omajid/c04b6025de49d0b7b18ab4a7e789484e: |
|
@omajid Oh very nice! Thanks! I saw how Fedora did x64 -> arm64 conversion of its Private.Source.Build.Artifacts, and figured that if all else fails that's how I'd implement that. I am wondering, though, how a local Private.Source.Build.Artifacts file can be built for proper N-1 => N builds. Whether I use linux-musl-x64 or alpine-3.x binaries, dotnet5 and dotnet6 still relies on those prebuilt binaries for building, which is not ideal. |
|
Going from N-1 to N should be straightforward. Every build of .NET 6 should produce a Fedora packages of .NET Core 3.1, .NET 5 and .NET 6 all use this approach. |
|
Oh wicked! I'll get that subpackage going on all three versions. |
|
Now back to dotnet6, I've implemented the proper artifacts file now with all linux-x64 nugets replaced linux-musl-x64 versions using your nappo.py utility. Archive gets successfully picked up in packages/archive. Unfortunately, source-build-reference-package is the first to be unhappy with this change: Indeed, SBRP doesn't know to look for runtime.linux-musl-x64.microsoft.netcore.ildasm. Anyway to help them in that regard? |
|
Looks like source-build-reference-package has no understanding of I was able to build source-build-reference-packages standalone on alpine with this patch: diff --git a/src/targetPacks/Directory.Build.targets b/src/targetPacks/Directory.Build.targets
index 3289635d..34f9af45 100644
--- a/src/targetPacks/Directory.Build.targets
+++ b/src/targetPacks/Directory.Build.targets
@@ -59,9 +59,19 @@
</Target>
<Target Name="GetILToolPackageReferences">
+ <Exec IgnoreExitCode="true" Command="ldd --version 2>&1 | grep -q musl">
+ <Output TaskParameter="ExitCode" PropertyName="OSPlatformIsMuslCheck" />
+ </Exec>
+
+ <PropertyGroup>
+ <OSPlatformIsMusl Condition="$(OSPlatformIsMuslCheck) == '0'">true</OSPlatformIsMusl>
+ <OSPlatformIsMusl Condition="$(OSPlatformIsMusl) == ''">false</OSPlatformIsMusl>
+ </PropertyGroup>
+
<PropertyGroup>
<_OSPlatform Condition="$([MSBuild]::IsOSPlatform('windows'))">win</_OSPlatform>
<_OSPlatform Condition="$([MSBuild]::IsOSPlatform('linux'))">linux</_OSPlatform>
+ <_OSPlatform Condition="$([MSBuild]::IsOSPlatform('linux')) and '$(OSPlatformIsMusl)' == 'true'">linux-musl</_OSPlatform>
<_OSPlatform Condition="$([MSBuild]::IsOSPlatform('osx'))">osx</_OSPlatform>
<_OSPlatform Condition="$([MSBuild]::IsOSPlatform('freebsd'))">freebsd</_OSPlatform>
<_OSPlatform Condition="$([MSBuild]::IsOSPlatform('netbsd'))">netbsd</_OSPlatform>
Could you apply this patch to your dotnet6 sources and try out building it? |
|
That did it! Now it's command-line-api time to shine! Same error, I imagine it's also a matter of doing above change somewhere |
|
This ones not as obvious, command-line-api pulls source-build, which is where the bug occurs. It seems like it's not the only issue. Missing packages: Arch being=win-x64, win-x86, osx-x64, linux-x64. Original Private.Sourcebuilt.Artifacts doesn't have any nupkgs for win-x64, win-x86, osx-x64, so I'm rather confused where source-build would usually pull these, and system.reactive.core is another question mark. Full log: |
|
Fixed issues relating to missing packages. Only issue is that those packages are rejected unless the exact version is provided. In my experience, that shouldn't matter as it'll simply give a warning that a different version was resolved. It is my understanding that when revolving is disabled, it is for stable builds. Any way to make command-line-api more lax in that regard? |
|
I am not sure. Maybe @crummel, @lbussell or @MichaelSimons can help us out? |
omajid
referenced
this issue
in omajid/source-build-reference-packages
Jan 18, 2022
Originally reported at https://github.com/dotnet/installer/issues/12859 Use the same logic as dotnet-isntall.sh to identify whether a system is musl-based or not. For musl-based Linux systems, use `linux-musl` as the platform name, which leads to better RID names. Otherwise, we end up trying to use artifacts with an incorrect RID on musl based systems. In particular, we look for `runtime.linux-x64.microsoft.netcore.ildasm` which doesn't work on musl-based systems. It's also not produced by source-build builds, which makes building using a previous build of source-build impossible.
omajid
referenced
this issue
in omajid/source-build-reference-packages
Jan 18, 2022
Originally reported at https://github.com/dotnet/installer/issues/12859 Use the same logic as dotnet-isntall.sh to identify whether a system is musl-based or not. For musl-based Linux systems, use `linux-musl` as the platform name, which leads to better RID names. Otherwise, we end up trying to use artifacts with an incorrect RID on musl based systems. In particular, we look for `runtime.linux-x64.microsoft.netcore.ildasm` which doesn't work on musl-based systems. It's also not produced by source-build builds, which makes building using a previous build of source-build impossible.
|
Fixed this issue with two tricks.
That seemed to have fixed this issue. Evidently, this patch won't work with arm, but I'll cross that bridge when I have to. |
|
Bon, un autre. This time with aspnet core: This particular target file has logics in place for musl, it seems. Just maybe not the right logics. Investigating further |
|
A note: I've excluded all linux-x64 and fedore33 nupkgs from artifacts, and replaced them with their musl counterparts. Idk how ill-advised that was, but I figured that non-musl binaries had no place in my build process, and would perhaps complicate debugging. Are there reasons to keep these, apart from crossgen use cases? |
|
Well, that was easy! It turns out aspnetcore's build.sh has an --os-name argument where inserting linux-musl solves that particular issue. Thus modified repos/aspnetcore.proj injecting that build argument. Now to wait for the next failure, hopefully the end is near. edit This had a downstream effect to installer, which looked for certain linux-x64 artifacts. Simple fix in repos/installer.proj by adjusting AspNetCoreSharedFxInstallerRid to linux-musl-$(Platform) |
|
Another issue with installer: it's asking for microsoft.netcore.app.crossgen2.linux-x64 rather than its musl counterpart. Despite setting OSName to linux-musl for installer's build.sh, no dice. Error |
MichaelSimons
referenced
this issue
in dotnet/source-build-reference-packages
Jan 19, 2022
Originally reported at https://github.com/dotnet/installer/issues/12859 Use the same logic as dotnet-isntall.sh to identify whether a system is musl-based or not. For musl-based Linux systems, use `linux-musl` as the platform name, which leads to better RID names. Otherwise, we end up trying to use artifacts with an incorrect RID on musl based systems. In particular, we look for `runtime.linux-x64.microsoft.netcore.ildasm` which doesn't work on musl-based systems. It's also not produced by source-build builds, which makes building using a previous build of source-build impossible.
|
Well, terrific news! Found a fix for above error and build is complete. Installer had a few issues, here is the prelim patch that I've developped: I'm not sure if linux-musl-$(Platform) is stricly necessary. I'm gonna do more tests, and if so create a different TargetRid condition before creating a PR with installer (and indeed sudo is removed for my use-case, shouldn't be in final PR) |
MichaelSimons
referenced
this issue
in dotnet/source-build-reference-packages
Jan 20, 2022
Originally reported at https://github.com/dotnet/installer/issues/12859 Use the same logic as dotnet-isntall.sh to identify whether a system is musl-based or not. For musl-based Linux systems, use `linux-musl` as the platform name, which leads to better RID names. Otherwise, we end up trying to use artifacts with an incorrect RID on musl based systems. In particular, we look for `runtime.linux-x64.microsoft.netcore.ildasm` which doesn't work on musl-based systems. It's also not produced by source-build builds, which makes building using a previous build of source-build impossible.
|
New issue, when rebuilding with that first successful, rebuild fails with following error: edit Modifiying src/sourcelink.8031e5220baf2acad991e661d8308b783d2acf3e/artifacts/source-build/self/package-cache/system.text.json/6.0.1/system.text.json.nuspec with actual version fixed this - no idea why this is an issue now. |
|
Well... So this business of mismatched versions is really curious. Anyone's got an idea on what this is about? The first build had only one instance of this bug (see above issue relating to command-line-api), but it cleared up once I added missing nuget edit it's especially odd, as prebuilt Artifacts don't have 6.0.0 version of these files, so what changed b/w then and now? |
These issues looks like what I fixed with dotnet/installer#13009 |
|
@MichaelSimons Wicked, I'll try it out. I imagine this'll require rebuilding the first build, right? |
Yes. |
|
Libary question: runtime provides a set of .so libraries under shared/, is there a mechanism by which one can symbolically link these to /usr/lib? Would there be a point for this? Just weirded out by the ArchLinux team symbolically linking hostfxr.so to /usr/lib, and since the Alpine Linux builder is warning about a missing libmscordaccore.so, I was wanting to explore how I could provide it in a global setting. Problem is that if every runtime version provides a /usr/lib link, than they'll be conflicts. One can imagine, say a symbolic link in /usr/lib/libmscordaccore.so.6 that links to /usr/share/dotnet/shared/Microsoft.NETCore.App/6.0.1/libmscordaccore.so. |
|
Your patch did it, Michael. Thanks! And hooray! We've got a full build going!!! Not so fast, though. While I've managed to build dotnet6 in my environment on itself, for some reason, when the whole stack gets rebuilt within a docker container on Alpine's Gitlab pipeline, I get the following error during aspnet-core's build: Last time I got a code 139 with anything was when trying to execute linux-x64 built ilasm on linux-musl-x64. Given that this binary comes from a linux-musl-x64 nupkg, I'm weirded out. An LDD of crossgen2 confirms that all shared objects are accounted for. All libraries are the same except my environment has lttn-ust version 2.13.1 while the other environment has 2.13.0, Both being broken, I set Full log: https://gitlab.alpinelinux.org/ayakael/aports/-/jobs/601533/raw |
|
I couldn't figure out the best area label to add to this issue. If you have write-permissions please help me learn by adding exactly one area label. |
|
@MichaelSimons Many thanks! |
|
@omajid How did you get s390x architecture built on Fedora without prebuilt binaries? Did you crosscompile? |
This was referenced Mar 10, 2022
To plug easily into the current build process, it'd be a question of indeed having a prebuilt tarball available online similar to |
This was referenced Mar 10, 2022
|
I'm experimenting with https://github.com/redhat-developer/dotnet-regular-tests/ to see about using that testing suite for alpine. Unfortunately, lots of tests fail with dotnet 6.0.3, which makes me wonder if the testing suite is the problem. How portable is this testing suite to |
|
That test suite was designed and tested with the assumption that it would be testing rpm-packaged .NET SDKs in a rpm+glibc based Linux distribution. There are going to be lots of test failures on other environments, even on If you are interested, we can try and improve that test suite by diasbling certain tests on Or, better yet, help me add Alpine to the CI matrix ? |
I think the SDK would have to be cross compiled, though I am not sure what a good cross-compile environment for linux-musl is. You don't need a full Private.SourceBuilt.Artifacst for s390x. Adding just a few nuget packages to the existing linux-musl-x64 version of the tarball will do the trick: |
|
I created the initial bootstrap SDK via cross-compile on an Ubuntu 18.04, using the cross-compilers and cross-libraries that come with the distribution. The resulting binaries run on Ubuntu 18.04 or later, as well as on RHEL 8 and current Fedora versions. However, they're unlikely to run on a musl based distro. It should be straightforward to run a similar cross-compile process targeting Alpine (I'd be happy to share the scripts I'm using), but I think we'll have to set up a proper cross-compile environment first. Maybe using an existing s390x Alpine as a sysroot? |
|
@uweigand I'd appreciate access to those scripts :) As a package maintainer, I've never had the chance to experiment with crosscompiling, so this looks like a fun project. Ideally, I'd like to be able to run a single script in a The completionist in me would eventually like to build for BTW excellent news, |
|
One last thing that has been in the back of mind is the naming convention. Why is runtime packaged under edit I'll keep as is, as in dotnetx-runtime and dotnetx-sdk to match upstream. |
|
In trying to move the dotnet6 package to the community repo on Alpine, an error has appeared: Similar bug to what appears here: dotnet/runtime#23650 Any ideas what this is about? @wfurt perhaps? |
|
Above bug was introduced with musl 1.2.3, opened up an issue with runtime here dotnet/runtime#67763 |
|
dotnet6 is now in community, rejoice! After many moons of work, it is time to close this issue |
@ayakael sorry for the late reply, I've been out sick. Not sure if you still need those at this point, but I've attached the set of scripts I've been using to cross-build a 6.0.100 SDK for s390x. These are intended to run on Ubuntu 20.04 (or 18.04) with a cross-compile environment targeting s390x installed. |
|
@uweigand Awesome, much obliged! Do you consent for me to share this with a select few Alpine developpers so we can work on creating this cross-compile environment on Alpine? (I mean I know its a public forum here, but you know, due diligence) |
|
Absolutely, feel free to share. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
I am currently working on an Alpine Linux dotnet6 package, and in the process of having packages merged for dotnet31 and dotnet5. As the build process is different for dotnet6 and above, I've been working on redesigning the APKBUILD.
Here is the repo where the work is being done: https://gitlab.alpinelinux.org/ayakael/aports/-/tree/testing/dotnet6
Patch notes
Aspnetcore doesn't build certain packages every build, This patches forces building them.
It is expected that location of --with-packages should be writable, thus allowing SBRP to be moved. In cases where Artifacts are provided by distro packages (like with Fedora and Alpine), that folder will be read-only. Thus build fails when there is an attempt at moving SBRP. This patch adjusts so that SBRP is copied rather than moved.
Aspnetcore looks for linux-x64 version of nupkgs that, under Alpine, should be linux-musl-x64. Adjusting aspnetcore has a downstream effect on installer, thus needing adjustment there as well.
Command-line-api looks for Runtime nupkgs for non-musl systems, causing errors as they are not provided by artifacts package. This patch fixes this by making linux-nusl-x64 the only platform supported
This makes things work better in a source-tarball build, where there may be a .git directory but it's for a different repo than command-line-api.
This makes things work better in a source-tarball build, where there may be a .git directory but it's for a different repo than fshap.
This makes the "portable" tarball portable to musl-based Linux distributions as well.
Add logic to convert internal repo uris in version.details.xml
Installer doesn't know to look for CrossGen2 nupkg on anything other than linux-$(BuildArchitecture). It should rather be $(SharedFrameworkRid) to match actual RID,
Adds RID for Alpine 3.15
Disable package validation which breaks build.
Runtime doesn't know to look for linux-musl version of Microsoft.NETCore.Ilasm nupkgs. This forces looking for it
Runtime doesn't generate a proper distro-rid for Alpine, leaving the last version digit. This, treating the RID like RHEL, removes the trailing digit
Similar to aspnetcore, not all packages are built every build. This forces building them.
Optouts of SDK telemetry
Use the same logic as dotnet-isntall.sh to identify whether a system is musl-based or not. For musl-based Linux systems, use
linux-muslas the platform name, which leads to better RID names.This makes things work better in a source-tarball build, where there may be a .git directory somewhere in our parent directories but it's for a different repo than vstest
This makes things work better in a source-tarball build, where there may be a .git directory somewhere in our parent directories but it's for a different repo than xliff-tasks
For issue page for dotnet31 and dotnet5 package, please see #2695
The text was updated successfully, but these errors were encountered: