VoidLinux dotnet discussion

[rmboggs]

Opening issue to continue discussion on packaging dotnet on VoidLinux.

[rmboggs]

Just updates:
I'm still trying to tweek the template files but dotnet7 is packaging and installing correctly. Still testing it on my machine. Also began updating the dotnet6 package files but it's not ready for packaging yet. Both projects are currently in the dotnet-work-NOMERGE branch for safe keeping while I continue working on them. Once they are ready, I'll create new branches for the appropriate pull requests. Feel free to browse, test, try out, comment, etc. that can help get this imported into the void-packages repo.

[Anachron]

Good job!

I'll check if Jellyfin is working with this... are there any issues you're aware of?

[rmboggs]

Good job!

I'll check if Jellyfin is working with this... are there any issues you're aware of?

I'm not sure about jellyfin. I haven't tried using it on here yet.

Dotnet 7 seems to be working ok. I'm doing another build on my machine now to make sure.

Dotnet 6 is giving me trouble now. The last 2 attempts I tried locally have failed. After 7 finishes, im gonna try again with different settings.

[rmboggs]

Updates: Both dotnet 6 and 7 are building fine now. They were included in the latest commit of the work branch. I'm looking through it again and I am wondering if I need to put in conflicts or something to avoid situations where the user tries to install both sets of packages. Open to thoughts on this one.

[Anachron]

Good job!

Sadly I'm still sick, but I hope I can test this soon and package jellyfin for it. (Already have the old templates, I just need to update them)

[ayakael]

On Alpine, dotnet7 and dotnet6 both build and package dotnet-host, netstandard21-targeting-pack, dotnet-docs and dotnet-{zsh,bash}-completion. This allows the most recent version to be installed. The rest of the subpackages should not conflict. dotnet-host brings all versions together, and the rest will work with dotnet6 and dotnet7.

[rmboggs]

Hi @ayakael ,
Sorry that I didn't notice you last message. Good news is that I was able to get dotnet7 and dotnet6 to finally work together in a very similar fashion than what you described. The changes are recorded in the work branch.

I'm finally starting to get work on the musl part. Setting up the cross build environment and will try a build on that side to see what crashes hard then figure out how to make musl specific patches on here. So... progresss. :)

Unfortunately, I noticed that a new version of dotnet7 recently dropped so I started working on that. I was hoping that it would be a simple switch but, unfortunately, I was mistaken. When I try to pkg 7.0.101, the build fails due to a missing crossgen2 tool that looks to be omitted from the source build. I need to investigate further on this so I branched that update separately and pushed it here as well. I need to look further on this to see what I can do for this failure.

Thanks,
Ryan

[mjeveritt]

Thank you for your efforts, Ryan, and good luck with musl libc!

[JamiKettunen]

@rmboggs For musl did you use a separate masterdir as per https://github.com/void-linux/void-packages#building-for-musl? You mentioned cross-compiling which afaik isn't supported for any package really in terms of cross-libc, glibc masterdir -> musl target or vice versa, it's a pure coincidence if that happens to work for some package.

If you meant cross-compiling as in architecture wise then I'd say worry about that a bit later and get native musl libc compilation working first as a stepping stone

[ayakael]

Hi @ayakael , Sorry that I didn't notice you last message. Good news is that I was able to get dotnet7 and dotnet6 to finally work together in a very similar fashion than what you described. The changes are recorded in the work branch.

I'm finally starting to get work on the musl part. Setting up the cross build environment and will try a build on that side to see what crashes hard then figure out how to make musl specific patches on here. So... progresss. :)

Unfortunately, I noticed that a new version of dotnet7 recently dropped so I started working on that. I was hoping that it would be a simple switch but, unfortunately, I was mistaken. When I try to pkg 7.0.101, the build fails due to a missing crossgen2 tool that looks to be omitted from the source build. I need to investigate further on this so I branched that update separately and pushed it here as well. I need to look further on this to see what I can do for this failure.

Thanks, Ryan

Could you share the error log that you encountered with crossgen2? There were some important infrastructure changes integrated to 7.0.101 via dotnet/installer#14549, so maybe it is related to that.

Also - as for musl bootstraps, the SDK that Microsoft provides for alpine should also work for void as they actually target linux-musl. Crosscompiling should thus only be necessary for anything that is not x86_64, aarch64 and armv7. If eventually you should want to target other arches, I host Alpine bootstraps for s390x and ppc64le here. They target linux-musl so they should work, but YMMV.

[rmboggs]

@rmboggs For musl did you use a separate masterdir as per https://github.com/void-linux/void-packages#building-for-musl? You mentioned cross-compiling which afaik isn't supported for any package really in terms of cross-libc, glibc masterdir -> musl target or vice versa, it's a pure coincidence if that happens to work for some package.

If you meant cross-compiling as in architecture wise then I'd say worry about that a bit later and get native musl libc compilation working first as a stepping stone

Yeah, I'm only referring x86_64-musl here. I was not planning on looking into things like ARM or anything like that at the moment for this.

And i am using the doc you mentioned above for building musl binaries with a different masterdir. I just got distracted with the recent dotnet 7 update that was just released.

[rmboggs]

Hi @ayakael , Sorry that I didn't notice you last message. Good news is that I was able to get dotnet7 and dotnet6 to finally work together in a very similar fashion than what you described. The changes are recorded in the work branch.
I'm finally starting to get work on the musl part. Setting up the cross build environment and will try a build on that side to see what crashes hard then figure out how to make musl specific patches on here. So... progresss. :)
Unfortunately, I noticed that a new version of dotnet7 recently dropped so I started working on that. I was hoping that it would be a simple switch but, unfortunately, I was mistaken. When I try to pkg 7.0.101, the build fails due to a missing crossgen2 tool that looks to be omitted from the source build. I need to investigate further on this so I branched that update separately and pushed it here as well. I need to look further on this to see what I can do for this failure.
Thanks, Ryan

Could you share the error log that you encountered with crossgen2? There were some important infrastructure changes integrated to 7.0.101 via dotnet/installer#14549, so maybe it is related to that.

Yeah, it could be related to that pull. I posted the aspnetcore log file that contains the details to this gist for reference. It's just not finding that crossgen2 program to finish building aspnetcore.

Also - as for musl bootstraps, the SDK that Microsoft provides for alpine should also work for void as they actually target linux-musl. Crosscompiling should thus only be necessary for anything that is not x86_64, aarch64 and armv7. If eventually you should want to target other arches, I host Alpine bootstraps for s390x and ppc64le here. They target linux-musl so they should work, but YMMV.

Thanks for the head up on on the bootstraps. I'm going to see if I can get back to the musl build now using 7.0.100 as that version is working well on my machine now. Hoping that if the musl piece goes well, I can make a formal pull request for both 6 and 7 soon but with the holiday season now, probably won't happen until after the new year.

[ayakael]

Hi @ayakael , Sorry that I didn't notice you last message. Good news is that I was able to get dotnet7 and dotnet6 to finally work together in a very similar fashion than what you described. The changes are recorded in the work branch.
I'm finally starting to get work on the musl part. Setting up the cross build environment and will try a build on that side to see what crashes hard then figure out how to make musl specific patches on here. So... progresss. :)
Unfortunately, I noticed that a new version of dotnet7 recently dropped so I started working on that. I was hoping that it would be a simple switch but, unfortunately, I was mistaken. When I try to pkg 7.0.101, the build fails due to a missing crossgen2 tool that looks to be omitted from the source build. I need to investigate further on this so I branched that update separately and pushed it here as well. I need to look further on this to see what I can do for this failure.
Thanks, Ryan

Could you share the error log that you encountered with crossgen2? There were some important infrastructure changes integrated to 7.0.101 via dotnet/installer#14549, so maybe it is related to that.

Yeah, it could be related to that pull. I posted the aspnetcore log file that contains the details to this gist for reference. It's just not finding that crossgen2 program to finish building aspnetcore.

Also - as for musl bootstraps, the SDK that Microsoft provides for alpine should also work for void as they actually target linux-musl. Crosscompiling should thus only be necessary for anything that is not x86_64, aarch64 and armv7. If eventually you should want to target other arches, I host Alpine bootstraps for s390x and ppc64le here. They target linux-musl so they should work, but YMMV.

Thanks for the head up on on the bootstraps. I'm going to see if I can get back to the musl build now using 7.0.100 as that version is working well on my machine now. Hoping that if the musl piece goes well, I can make a formal pull request for both 6 and 7 soon but with the holiday season now, probably won't happen until after the new year.

Hmm, I've had issues with crossgen2 before on aspnetcore, but not this particular one. Can you try building with /p:UseNonPortableIlasmPackageOverride=true? This turns on some extra logics to find the crossgen2 package. If all else fails, you can also set /p:CrossgenOutput=false which disables usage of crossgen in aspnetcore.

[rmboggs]

Hi @ayakael , Sorry that I didn't notice you last message. Good news is that I was able to get dotnet7 and dotnet6 to finally work together in a very similar fashion than what you described. The changes are recorded in the work branch.
I'm finally starting to get work on the musl part. Setting up the cross build environment and will try a build on that side to see what crashes hard then figure out how to make musl specific patches on here. So... progresss. :)
Unfortunately, I noticed that a new version of dotnet7 recently dropped so I started working on that. I was hoping that it would be a simple switch but, unfortunately, I was mistaken. When I try to pkg 7.0.101, the build fails due to a missing crossgen2 tool that looks to be omitted from the source build. I need to investigate further on this so I branched that update separately and pushed it here as well. I need to look further on this to see what I can do for this failure.
Thanks, Ryan

Could you share the error log that you encountered with crossgen2? There were some important infrastructure changes integrated to 7.0.101 via dotnet/installer#14549, so maybe it is related to that.

Yeah, it could be related to that pull. I posted the aspnetcore log file that contains the details to this gist for reference. It's just not finding that crossgen2 program to finish building aspnetcore.

Also - as for musl bootstraps, the SDK that Microsoft provides for alpine should also work for void as they actually target linux-musl. Crosscompiling should thus only be necessary for anything that is not x86_64, aarch64 and armv7. If eventually you should want to target other arches, I host Alpine bootstraps for s390x and ppc64le here. They target linux-musl so they should work, but YMMV.

Thanks for the head up on on the bootstraps. I'm going to see if I can get back to the musl build now using 7.0.100 as that version is working well on my machine now. Hoping that if the musl piece goes well, I can make a formal pull request for both 6 and 7 soon but with the holiday season now, probably won't happen until after the new year.

Hmm, I've had issues with crossgen2 before on aspnetcore, but not this particular one. Can you try building with /p:UseNonPortableIlasmPackageOverride=true? This turns on some extra logics to find the crossgen2 package. If all else fails, you can also set /p:CrossgenOutput=false which disables usage of crossgen in aspnetcore.

Tried both, the only one that built was /p:CrossgenOutput=false. I'm not 100% sure what other impacts this option has. Not sure it is a good choice for packaging.

I haven't installed the built package or tried using it yet. I want some more opinions before I proceed with that.

[rmboggs]

Hi,

Sorry to be away for awhile. Been really busy with work and the holidays. Since last post, not too much has changed. I got dotnet7 updated to 7.0.102 and working fine. I still need the CrossgenOutput patch unfortunately but I haven't seen anything out of the ordinary with it so cautiously optimistic.

As far as musl goes, not much has changed yet. I tried cross compiling on my main system but didn't like that setup so I just setup another laptop I had with void-linux-musl so I can try building and testing to make sure it's working ok before proceeding to next steps. So far not much progress as it is currently complaining that it cannot find the linux-musl-x64 nuget packages but I plan on taking a closer look at the apline dotnet repo to see what other settings I might need. Hoping to make progress soon on this front.

[darkralts]

based

[ayakael]

By the way, I've setup a pipeline on my personai Gitlab instance that automatically generates tarballs for new releases of dotnet. For dotnet6 and dotnet7, it is available here: https://lab.ilot.io/dotnet/installer/-/releases. For dotnet8: https://lab.ilot.io/dotnet/dotnet/-/releases. Y'all are welcome to use them.

Dotnet8-preview1 has also been packaged here: https://gitlab.alpinelinux.org/ayakael/aports/-/merge_requests/15

edit
Finally, bootstraps for linux-musl-s390x and linux-musl-ppc64le are available here: https://lab.ilot.io/ayakael/dotnet-stage0/-/releases. I do not have a crossbuilding env for libc stuff, unfortunately.

[rmboggs]

@ayakael - Sorry for the delay, trying to circle back on this. Thank you for providing the links for the tarballs. Quick question though, and sorry for my limited understanding of this, how should these builds be applied to the package for musl builds?

FYI - I am in the middle of updating the dotnet7 package to 7.0.105. Dotnet6 has started giving me trouble again starting with 6.0.115 due to the distro RID being generated is now showing up as "void-x64" instead of "linux-x64" and the runtime build is not recognizing it. I've barely started investigating but I found the shell script that is causing the problem but still trying to see the best way to patch. I'll update here when I can make progress.

[rmboggs]

So, update:
Was able to get dotnet7 7.0.105 working on x86_64 as expected with little update effort. The dotnet-work-NOMERGE branch has been updated accordingly.

Surprisingly enough, 7.0.105 actually builds successfully on x86_64-musl on an actual musl machine but fails during the package process with an odd error:

SONAME: libc.musl-x86_64.so.1 <-> UNKNOWN PKG PLEASE FIX

After a bit of research, it looks like the common/shlibs needs to be updated to map that shared library but I am not sure which package it belongs to. However, I'm not 100% sure that is correct as this does look like a default library for musl, which means that I may need to update the template a bit just for musl.

Anyone have any thoughts on this?

[ayakael]

Ahh good news! I pushed a bunch of patches upstream to get dotnet7 to build with as little patching as possible. As for libc.musl, that sounds like a void package manager problem, which I can't help with.

For dotnet6, 6.0.115 saw some changes backported from dotnet7 by myself which removes the necessity to runtime twice (via runtime-portable). Unfortunately, upstream NACKed the last patch as it was deemed too risky. Ironically, this complicated things as the change is now in a half-backed state across the dotnet ecosystem. Everything is in, except the last change that brings everything together. Thus, I recommend you apply the patch I run on Alpine, which should fix the error that you are encountering. This also introduces logics that automatically adds unrecognized RIDs.

installer_14816-eliminate-portable-build.txt
(github refused to upload this as .patch)

Now, because void uses both libc and musl, it's a bit awkward RIDs-wise. To match how RIDs are set globally, there should be a void-x64 and void-musl-x64 RIDs. I've never used Void, so I don't know how your package manager and repos are setup for musl-variant of packages. Could you share a bit about that?

[ayakael]

Re bootstrapping: On Alpine, we skip ./prep.sh --bootstrap and directly fetch the bootstrap and artifacts tarballs ourselves. We do this as we want to checksum everything we pull. Also, by default the artifacts tarball doesn't contain musl-variant nupkgs. Thus, after unpacking we historically had to fetch the missing nupkgs on nuget.org and add them to the artifacts folders. Nowadays, our dotnetx-stage0 package actually builds them for us.

Coming back to the RID issue, you will like have some problems down the line due to dotnet interpreting your system (even when musl-based) as void-x64, thus always thinking that you are using libc. When building dotnet-based applications on void-musl, it'll pull linux rather than linux-musl nupkgs.

So, to fix this, I see two approaches:

• First is the quick and dirty approach. When building using musl with any dotnet applications (and dotnet build), you should set /p:TargetRid=linux-musl-$arch. When building using libc, you should set /p:TargetRid=linux-$arch. You will have to pull the linux-musl variants of the nupkgs in the artifacts tarball and put them where dotnet will expect them. The build doesn't work on Alpine, but I think I just need to silence an aspectcore error that is benign.

• Second is the proper approach. There should be a void-musl-$arch RIDs added, and runtime should be able to detect it. I'm not sure the extent of the work that needs to be done, thus I would open up an issue in https://github.com/dotnet/source-build/issues to get help from upstream. I can propose a few patches that would get you along once that space is created.

[Anachron]

Thanks both for all the hard work!

I am just reading along to see when you call out for testers, I have both x86_64 and aarch64 hardware to test with (both glibc though).

[rmboggs]

@Anachron - dotnet7 is building and running on x86_64 glibc in the dotnet-work-NOMERGE branch of this repo if you want to start trying it out. Please be aware, however, that it takes a LONG time to build for me due to having older machines. I haven't put any work into the arm builds yet.

@ayakael - I finally got the pkg process to complete on my musl system for all the packages but I don't believe I fixed the libc.musl-x86_64.so.1 issue correctly. From what I can gathered, the issue seems to be in the dotnet-sdk component as it appears to be hardcoded to look for the so in question by name on musl machines even though it appears that it is just a link to libc.so. While Alpine seems to add the appropriate link in its musl package, other linux distros (such as Void and Gentoo) do not, based on this issue I found reported here in github. I may have to open an issue with the dotnet/sdk repo to check it out further.

On the plus side, except for dotnet-sdk, all of the other packages (runtimes, hosts, templates, targeting-packs, etc) for dotnet 7 built and installed without problems on void-musl. However, I have yet to test them thoroughly due to the sdk package issue.

I haven't had a chance to circle back to the dotnet 6 build yet. Based on @ayakael's previous comment regarding the current rid issue that I am dealing with, I do think the second approach would be ideal. My only question would be: "would it be possible for the new rids to be backported to version 6 or is it only possible to for version 7+ to be updated?" I'll need to ask and find out.

[rmboggs]

Did some more looking today. Looking at this doc and this doc too it looks like the minimum version of musl supported by dotnet is 1.2.2. Void is still on 1.1.*. I'm actually kinda surprised I am getting as far as I have been. Based on that, I'm not sure how much farther I can get until Void can update their musl base system to 1.2.2.

[mjeveritt]

Did some more looking today. Looking at this doc and this doc too it looks like the minimum version of musl supported by dotnet is 1.2.2. Void is still on 1.1.*. I'm actually kinda surprised I am getting as far as I have been. Based on that, I'm not sure how much farther I can get until Void can update their musl base system to 1.2.2.

I think I'd take that with a pinch of salt, but I can imagine why they've done that upstream...

I would say the path forward may not be impossible with 1.1.x but some of the shortcuts will likely be missing ..

[JamiKettunen]

I'd like to add that Void's musl is quite heavily patched to the point it's starting to resemble 1.2.x more than 1.1.x

[Anachron]

First, you gotta lint those templates ;-)

[24.04.2023-08:52:36] (dotnet7) lint:start
/home/lap/var/bldr/gitsrc/srcpkgs/dotnet7/template:6: Place homepage= after build_style=
/home/lap/var/bldr/gitsrc/srcpkgs/dotnet7/template:11: wrksrc is deprecated and should not be used
/home/lap/var/bldr/gitsrc/srcpkgs/dotnet7/template:15: custom variables should use _ prefix: installer_tag="v${version}"
/home/lap/var/bldr/gitsrc/srcpkgs/dotnet7/template:25: custom variables should use _ prefix: archive_name="Private.SourceBuilt.Artifacts.${_bootstrapver}.tar.gz"
/home/lap/var/bldr/gitsrc/srcpkgs/dotnet7/template:37: trailing whitespace
/home/lap/var/bldr/gitsrc/srcpkgs/dotnet7/template:214: Last line is empty
[24.04.2023-08:52:36] (dotnet7) lint:finish (RC=1)

Second, I guess you still need those symlinks ;-)

   [runtime] dotnet7-sdk-7.0.105_1: not found (subpkg, ignored)
   [runtime] aspnetcore7-runtime-7.0.105_1: not found (subpkg, ignored)
   [runtime] dotnet7-runtime-7.0.105_1: not found (subpkg, ignored)
   [runtime] dotnet7-hostfxr-7.0.105_1: not found (subpkg, ignored)
   [runtime] dotnet-host-7.0.105_1: not found (subpkg, ignored)
   [runtime] dotnet7-apphost-pack-7.0.105_1: not found (subpkg, ignored)
   [runtime] dotnet7-targeting-pack-7.0.105_1: not found (subpkg, ignored)
   [runtime] aspnetcore7-targeting-pack-7.0.105_1: not found (subpkg, ignored)
   [runtime] netstandard-targeting-pack-7.0.105_1: not found (subpkg, ignored)
   [runtime] dotnet7-templates-7.0.105_1: not found (subpkg, ignored)
   [runtime] dotnet7-runtime-7.0.105_1: not found (subpkg, ignored)
   [runtime] dotnet7-runtime-7.0.105_1: not found (subpkg, ignored)
   [runtime] dotnet7-runtime-7.0.105_1: not found (subpkg, ignored)
   [runtime] dotnet7-runtime-7.0.105_1: not found (subpkg, ignored)
   [runtime] dotnet-host-7.0.105_1: not found (subpkg, ignored)
   [runtime] dotnet7-hostfxr-7.0.105_1: not found (subpkg, ignored)
   [runtime] dotnet7-runtime-7.0.105_1: not found (subpkg, ignored)
   [runtime] aspnetcore7-runtime-7.0.105_1: not found (subpkg, ignored)
   [runtime] dotnet7-targeting-pack-7.0.105_1: not found (subpkg, ignored)
   [runtime] aspnetcore7-targeting-pack-7.0.105_1: not found (subpkg, ignored)
   [runtime] netstandard-targeting-pack-7.0.105_1: not found (subpkg, ignored)
   [runtime] dotnet7-apphost-pack-7.0.105_1: not found (subpkg, ignored)
   [runtime] dotnet7-templates-7.0.105_1: not found (subpkg, ignored)
   [runtime] dotnet7-runtime-7.0.105_1: not found (subpkg, ignored)
   [runtime] aspnetcore7-runtime-7.0.105_1: not found (subpkg, ignored)
   [runtime] dotnet7-targeting-pack-7.0.105_1: not found (subpkg, ignored)
   [runtime] aspnetcore7-targeting-pack-7.0.105_1: not found (subpkg, ignored)
   [runtime] netstandard-targeting-pack-7.0.105_1: not found (subpkg, ignored)
   [runtime] dotnet7-apphost-pack-7.0.105_1: not found (subpkg, ignored)
   [runtime] dotnet7-templates-7.0.105_1: not found (subpkg, ignored)
   [runtime] dotnet7-runtime-7.0.105_1: not found (subpkg, ignored)
   [runtime] aspnetcore7-runtime-7.0.105_1: not found (subpkg, ignored)
   [runtime] dotnet7-targeting-pack-7.0.105_1: not found (subpkg, ignored)
   [runtime] aspnetcore7-targeting-pack-7.0.105_1: not found (subpkg, ignored)
   [runtime] netstandard-targeting-pack-7.0.105_1: not found (subpkg, ignored)
   [runtime] dotnet7-apphost-pack-7.0.105_1: not found (subpkg, ignored)
   [runtime] dotnet7-templates-7.0.105_1: not found (subpkg, ignored)
   [runtime] dotnet7-runtime-7.0.105_1: not found (subpkg, ignored)
   [runtime] aspnetcore7-runtime-7.0.105_1: not found (subpkg, ignored)
   [runtime] dotnet7-targeting-pack-7.0.105_1: not found (subpkg, ignored)
   [runtime] aspnetcore7-targeting-pack-7.0.105_1: not found (subpkg, ignored)
   [runtime] netstandard-targeting-pack-7.0.105_1: not found (subpkg, ignored)
   [runtime] dotnet7-apphost-pack-7.0.105_1: not found (subpkg, ignored)
   [runtime] dotnet7-templates-7.0.105_1: not found (subpkg, ignored)

Edit: Looks good:

=> Registering new packages to /host/binpkgs/dotnet-work-NOMERGE
index: added `aspnetcore7-runtime-7.0.105_1' (x86_64).
index: added `aspnetcore7-targeting-pack-7.0.105_1' (x86_64).
index: added `dotnet-host-7.0.105_1' (x86_64).
index: added `dotnet7-7.0.105_1' (x86_64).
index: added `dotnet7-apphost-pack-7.0.105_1' (x86_64).
index: added `dotnet7-hostfxr-7.0.105_1' (x86_64).
index: added `dotnet7-runtime-7.0.105_1' (x86_64).
index: added `dotnet7-sdk-7.0.105_1' (x86_64).
index: added `dotnet7-targeting-pack-7.0.105_1' (x86_64).
index: added `dotnet7-templates-7.0.105_1' (x86_64).
index: added `netstandard-targeting-pack-7.0.105_1' (x86_64).
index: 11 packages registered.
=> dotnet7-7.0.105_1: running do_clean ...
=> dotnet7-7.0.105_1: removing autodeps, please wait...
=> dotnet7-7.0.105_1: cleaning build directory...
=> dotnet7: removing files from destdir...
=> aspnetcore7-runtime: removing files from destdir...
=> aspnetcore7-targeting-pack: removing files from destdir...
=> dotnet-host: removing files from destdir...
=> dotnet7-apphost-pack: removing files from destdir...
=> dotnet7-hostfxr: removing files from destdir...
=> dotnet7-runtime: removing files from destdir...
=> dotnet7-sdk: removing files from destdir...
=> dotnet7-targeting-pack: removing files from destdir...
=> dotnet7-templates: removing files from destdir...
=> netstandard-targeting-pack: removing files from destdir...
[24.04.2023-09:52:16] (dotnet7) pkg:finish (RC=0)

Took around 1 hour with a 1240P Intel CPU:

[24.04.2023-08:54:26] (dotnet7) build:start
[24.04.2023-09:51:30] (dotnet7) build:finish (RC=0)

I find it a bit disturbing just how big this builddir is:
103287 directories, 436911 files

[ayakael]

@rmboggs

Glad to be of service! They should be arch agnostic as they don't contain any prebuilts, just source code.

It's a relief that, with dotnet8, this business of building tarballs won't be necessary. We can pull the source code directly from the GitHub repo now.

[rmboggs]

@ayakael - Thanks, good to know.

Sounds like it's going to be awhile before the updated openssl packages will be available, unfortunately. So it'll be some time before I can actually get this work off the ground. May not be able to pick up until tomorrow. My timing sux.

Based on my testing from yesterday, I believe that I just need to need to unzip the contents into the ${wrksrc}/sources directory but I need to move it up one directory with the following command:

tar -x -J -v --strip-components=1 -f path/to/file.xz

[Anachron]

If there is anything I can do to help, let me know. I am happy to test things on both x86_64 and aarch64.

Until then, good luck!

[rmboggs]

If there is anything I can do to help, let me know. I am happy to test things on both x86_64 and aarch64.

Until then, good luck!

Thanks, my current hold up is waiting for the openssl updates to hit the void servers so i can test withoit rebuilding everything manually. I'll keep you all posted.

[rmboggs]

FYI - The build is failing in the installer step that is complaining that the generated source link is empty. I posted build log in the Gist linked below. I'm either not setting something in the build correctly or I am missing more downloads? Anyone have any ideas?

https://gist.githubusercontent.com/rmboggs/f9091b63166d92d7f4a113be3adad46a/raw/2ab2bf26ec1f95b781cfec0ac378fc4b1b38cece/installer.log

[ayakael]

We also get this error on Alpine Linux. The following patch workarounds the issue:

From 98054ea87ce70247bb09ceafd2ad1a0b36d2fef4 Mon Sep 17 00:00:00 2001
From: Antoine Martin <dev@ayakael.net>
Date: Sat, 1 Oct 2022 09:21:58 -0400
Subject: [PATCH] Disable source link

Addresses undiagnosed "Source control information is not available" error

---
diff --git a/repos/installer.proj b/repos/installer.proj
index 3a9756a27b7..4968184b14e 100644
--- a/repos/installer.proj
+++ b/repos/installer.proj
@@ -26,6 +26,7 @@
     -->
     <BuildCommandArgs>$(BuildCommandArgs) /p:NETCoreAppMaximumVersion=99.9</BuildCommandArgs>
     <BuildCommandArgs>$(BuildCommandArgs) /p:OSName=$(OSNameOverride)</BuildCommandArgs>
+    <BuildCommandArgs>$(BuildCommandArgs) /p:EnableSourceLink=false</BuildCommandArgs>
     <BuildCommandArgs>$(BuildCommandArgs) /p:PortableOSName=$(PortableOS)</BuildCommandArgs>
     <BuildCommandArgs Condition="'$(TargetOS)' == 'Linux'">$(BuildCommandArgs) /p:Rid=$(TargetRid)</BuildCommandArgs>
     <BuildCommandArgs>$(BuildCommandArgs) /p:DOTNET_INSTALL_DIR=$(DotNetCliToolDir)</BuildCommandArgs>
``

[ayakael]

By the way, I'm working on getting dotnet6 builds working on linux-musl without patches:
dotnet/installer#17324

This is only necessary if you do not use the Alpine patches that drops runtime-portable step.

[rmboggs]

We also get this error on Alpine Linux. The following patch workarounds the issue:

From 98054ea87ce70247bb09ceafd2ad1a0b36d2fef4 Mon Sep 17 00:00:00 2001
From: Antoine Martin <dev@ayakael.net>
Date: Sat, 1 Oct 2022 09:21:58 -0400
Subject: [PATCH] Disable source link

Addresses undiagnosed "Source control information is not available" error

---
diff --git a/repos/installer.proj b/repos/installer.proj
index 3a9756a27b7..4968184b14e 100644
--- a/repos/installer.proj
+++ b/repos/installer.proj
@@ -26,6 +26,7 @@
     -->
     <BuildCommandArgs>$(BuildCommandArgs) /p:NETCoreAppMaximumVersion=99.9</BuildCommandArgs>
     <BuildCommandArgs>$(BuildCommandArgs) /p:OSName=$(OSNameOverride)</BuildCommandArgs>
+    <BuildCommandArgs>$(BuildCommandArgs) /p:EnableSourceLink=false</BuildCommandArgs>
     <BuildCommandArgs>$(BuildCommandArgs) /p:PortableOSName=$(PortableOS)</BuildCommandArgs>
     <BuildCommandArgs Condition="'$(TargetOS)' == 'Linux'">$(BuildCommandArgs) /p:Rid=$(TargetRid)</BuildCommandArgs>
     <BuildCommandArgs>$(BuildCommandArgs) /p:DOTNET_INSTALL_DIR=$(DotNetCliToolDir)</BuildCommandArgs>
``

Thanks @ayakael, that fixed it. It builds successfully now. Let me see if I can post the new template files somewhere for someone else to test.

[rmboggs]

New working dotnet 7 template file with correct references to @ayakael stage files can be found here for review and critique if interested.

https://github.com/void-dotnet/staging/blob/main/srcpkgs/dotnet7/template

[chrysos349]

@rmboggs Great job! I successfully packaged Parabolic (a dotnet gnome app), thanks to your efforts!

I see you disabled the telemetry in the template. You can also set the DOTNET_NOLOGO environment variable to true to disable .NET welcome message.

vsed -e "s|\"DOTNET_NOLOGO\", defaultValue: false|\"DOTNET_NOLOGO\", defaultValue: true|" -i sources/src/sdk/src/Cli/dotnet/Program.cs

By the way, here is the template I compiled:

# Template file for 'parabolic'
pkgname=parabolic
version=2023.9.0
revision=1
archs="x86_64"
build_style=meta
# requires blueprint-compiler>=0.10.0
hostmakedepends="blueprint-compiler dotnet7-sdk gettext icu-libs"
makedepends="libadwaita-devel"
depends="ffmpeg libadwaita yt-dlp"
short_desc="Easy-to-use video downloader"
maintainer="chrysos349 <chrysostom349@gmail.com>"
license="MIT"
homepage="https://github.com/NickvisionApps/Parabolic"
_commit=75d0c1859b062b57d73fb466321258b00c94d6ef
distfiles="https://github.com/NickvisionApps/Parabolic/archive/${version}.tar.gz
 https://github.com/NickvisionApps/CakeScripts/archive/${_commit}.tar.gz"
checksum="b2eb0f3701301b995aa393fe829bb632b3753565fbde1a926d9f3e7897f074ad
 3392fd030d6470b97b7f2b7085a7888192c9f5df99f67b546dcf5c40f0e47108"
noverifyrdeps=yes

post_extract() {
	mv Parabolic-*/{*,.config} .
	mv CakeScripts-*/* CakeScripts
}

do_configure() {
	dotnet tool restore
}

do_build() {
	dotnet cake --target=Publish --prefix=/usr --ui=gnome --self-contained
}

do_install() {
	dotnet cake --target=Install --destdir="${DESTDIR}"
}

post_install() {
	vlicense LICENSE
}

[JamiKettunen]

@chrysos349 Neat stuff, I feel like there definitely could be a dotnet build style later on which shrinks the template in case things are common for most programs :)

Btw meta build-style is for meta-packages (ones without any package contents only dependencies), you can leave it out entirely for your case at the moment

[rmboggs]

@chrysos349 Neat stuff, I feel like there definitely could be a dotnet build style later on which shrinks the template in case things are common for most programs :)

Yes, but first thing is first. ;)

Btw meta build-style is for meta-packages (ones without any package contents only dependencies), you can leave it out entirely for your case at the moment

Is this for the dotnet 7 item? If so, what build style should be used?

[JamiKettunen]

@rmboggs If the dotnet7 package is empty (without files/dirs) then build_style=meta makes sense, I was mainly only responding to the above parabolic template

[rmboggs]

@rmboggs If the dotnet7 package is empty (without files/dirs) then build_style=meta makes sense, I was mainly only responding to the above parabolic template

Ah ok, makes sense. Thanks.

[rmboggs]

Just an fyi - I will try to work on the x86_64-musl build next. if I remember correctly, I may need to request an update to the musl libs for void linux as during my previous tests, the dotnet libraries were looking for a specific musl library that Alpine Linux seems to include in their files but Void Linux does not. I believe it was just a simple symlink but need to look at it further.

If anyone wants to give arm64 a try, please feel free and let me know if changes to the template file are needed.

[Anachron]

If anyone wants to give arm64 a try, please feel free and let me know if changes to the template file are needed.

You're funny, you restricted archs to x86_64 and ask people to try to build for aarch64. ;-)

Also, all your symlinks are gone from the https://github.com/void-dotnet/staging/tree/main repo. That lets my build fail instantly.

I've done some

cd gitsrc/srcpkgs
ln -svT dotnet7 dotnet-host
ln -svT dotnet7 dotnet7-hostfxr
ln -svT dotnet7 dotnet7-runtime
ln -svT dotnet7 aspnetcore7-runtime
ln -svT dotnet7 dotnet7-sdk
ln -svT dotnet7 dotnet7-targeting-pack
ln -svT dotnet7 aspnetcore7-targeting-pack
ln -svT dotnet7 dotnet7-templates
ln -svT dotnet7 netstandard-targeting-pack
ln -svT dotnet7 dotnet7-apphost-pack

And it's building now. Will update once it's finished.

Edit:
My cross-compile failed with

Build FAILED.

  /builddir/dotnet7-7.0.110/sources/tools-local/init-build.proj(6,3): warning MSB4011: "/builddir/dotnet7-7.0.110/sources/git-info/AllRepoVersions.props" cannot be imported again. It was already imported at "/builddir/dotnet7-7.0.110/sources/Directory.Build.props (212,3)". This is most likely a build authoring error. This subsequent import will be ignored. 


"/builddir/dotnet7-7.0.110/sources/build.proj" (default target) (1) ->
"/builddir/dotnet7-7.0.110/sources/repos/known-good.proj" (Build target) (3) ->
"/builddir/dotnet7-7.0.110/sources/repos/runtime.proj" (Build target) (16) ->
(RepoBuild target) -> 
  /builddir/dotnet7-7.0.110/sources/repos/Directory.Build.targets(404,5): error MSB3073: The command "/builddir/dotnet7-7.0.110/sources/src/runtime/build.sh  --ci --configuration Release --restore --build --pack --publish -bl /p:ArcadeBuildFromSource=true /p:CopyWipIntoInnerSourceBuildRepo=true /p:DotNetBuildOffline=true /p:CopySrcInsteadOfClone=true /p:DotNetPackageVersionPropsPath="/builddir/dotnet7-7.0.110/sources/artifacts/obj/x64/Release/PackageVersions.props" /p:AdditionalSourceBuiltNupkgCacheDir="/builddir/dotnet7-7.0.110/sources/artifacts/obj/x64/Release/blob-feed/packages/" /p:ReferencePackageNupkgCacheDir="/builddir/dotnet7-7.0.110/sources/packages/reference/" /p:PreviouslySourceBuiltNupkgCacheDir="/builddir/dotnet7-7.0.110/sources/packages/previously-source-built/" /p:SourceBuildUseMonoRuntime= /p:TargetRid=void-x64 /p:RuntimeOS=linux /p:BaseOS=linux /p:SourceBuildNonPortable=true  /p:DotNetPackageVersionPropsPath=/builddir/dotnet7-7.0.110/sources/artifacts/obj/x64/Release/PackageVersions.props /p:DotNetRestoreSourcePropsPath=/builddir/dotnet7-7.0.110/sources/artifacts/obj/x64/Release/RestoreSources.props /p:DotNetBuildOffline=true >> /builddir/dotnet7-7.0.110/sources/artifacts/logs/runtime.log 2>&1" exited with code 1. [/builddir/dotnet7-7.0.110/sources/repos/runtime.proj]

    1 Warning(s)
    1 Error(s)

Time Elapsed 00:05:23.91
=> ERROR: dotnet7-7.0.110_1: do_build: './build.sh -- /v:n /p:LogVerbosity=n /p:SkipPortableRuntimeBuild=true' exited with 1
=> ERROR:   in do_build() at srcpkgs/dotnet7/template:85
[17.09.2023-21:01:47] (dotnet7) pkg:finish (RC=1)

Do I still need the patch from #1 (comment) ?

Edit2:
More from the log

    System.Private.CoreLib.Generators -> /builddir/dotnet7-7.0.110/sources/src/runtime/artifacts/source-build/self/src/artifac
ts/bin/System.Private.CoreLib.Generators/Release/netstandard2.0/System.Private.CoreLib.Generators.dll                         
    Microsoft.Interop.SourceGeneration -> /builddir/dotnet7-7.0.110/sources/src/runtime/artifacts/source-build/self/src/artifa
cts/bin/Microsoft.Interop.SourceGeneration/Release/netstandard2.0/Microsoft.Interop.SourceGeneration.dll                      
    LibraryImportGenerator -> /builddir/dotnet7-7.0.110/sources/src/runtime/artifacts/source-build/self/src/artifacts/bin/Libr
aryImportGenerator/Release/netstandard2.0/Microsoft.Interop.LibraryImportGenerator.dll                                        
    System.Private.CoreLib -> /builddir/dotnet7-7.0.110/sources/src/runtime/artifacts/source-build/self/src/artifacts/bin/Syst
em.Private.CoreLib/ref/Release/net7.0/System.Private.CoreLib.dll                                                              
  /builddir/dotnet7-7.0.110/sources/src/runtime/artifacts/source-build/self/src/eng/python.targets(21,5): error MSB3073: The c
ommand "..." exited with code 1. [/builddir/dotnet7-7.0.110/sources/src/runtime/artifacts/source-build/self/src/src/coreclr/Sy
stem.Private.CoreLib/System.Private.CoreLib.csproj]                                                                           
                                                                                                                            
  Build FAILED.                                                                                                               
                                                                                                                            
  /builddir/dotnet7-7.0.110/sources/src/runtime/artifacts/source-build/self/src/eng/python.targets(21,5): error MSB3073: The c
ommand "..." exited with code 1. [/builddir/dotnet7-7.0.110/sources/src/runtime/artifacts/source-build/self/src/src/coreclr/Sy
stem.Private.CoreLib/System.Private.CoreLib.csproj]                                                                           
      0 Warning(s)                                                                                                            
      1 Error(s)                                                                                                              
                                                                                                                            
  Time Elapsed 00:00:15.33                                                                                                    
  Build failed with exit code 1. Check errors above.              

[chrysos349]

Also, all your symlinks are gone from the https://github.com/void-dotnet/staging/tree/main repo. That lets my build fail instantly.

@Anachron not that hard to recreate all symlinks from the template. run this in srcpkgs dir:

for i in $(grep -Po '\K.*(?=_package\()' dotnet7/template ); do ln -sf dotnet7 $i; done

[ayakael]

I was thinking more about musl support. One thing I'd explore doing is, when using linux musl, set /p:TargetRid=void-musl-$arch and /p:AdditionalRuntimeIdentifierParent=linux-musl-$arch (and maybe /p:AdditionalRuntimeIdentifier=void-musl-$arch) What this should do is create the void-musl-$arch Rid, and make linux-musl-$arch its parent. Without doing this, I suspect that your TargetRid will come up as void-$arch with parent linux-$arch, thus build will pull glibc nupkgs rather than the libc-musl variants. Plus, whatever packages build using that dotnet will also pull glibc nupkgs.

Also, as explained a while ago, your Prebuilt artifacts tarball will need the linux-musl-$arch variants of the platform specific nupkgs for bootstrapping. You can source them off of nuget.org without issue, just make sure to match the versions provided by the artifacts tarball.

edit
Of note, dotnet8 does away with non-portable Rids. Thus, void-$arch will become linux-$arch and ditto for void-musl-$arch.

[rmboggs]

Also, all your symlinks are gone from the https://github.com/void-dotnet/staging/tree/main repo. That lets my build fail instantly.

Yeah, that's my bad. I didn't spend much time getting the template file up there. Sorry about that.

@Anachron not that hard to recreate all symlinks from the template. run this in srcpkgs dir:

for i in $(grep -Po '\K.*(?=_package\()' dotnet7/template ); do ln -sf dotnet7 $i; done

Thanks for that script.

[rmboggs]

I was thinking more about musl support. One thing I'd explore doing is, when using linux musl, set /p:TargetRid=void-musl-$arch and /p:AdditionalRuntimeIdentifierParent=linux-musl-$arch (and maybe /p:AdditionalRuntimeIdentifier=void-musl-$arch) What this should do is create the void-musl-$arch Rid, and make linux-musl-$arch its parent. Without doing this, I suspect that your TargetRid will come up as void-$arch with parent linux-$arch, thus build will pull glibc nupkgs rather than the libc-musl variants. Plus, whatever packages build using that dotnet will also pull glibc nupkgs.

Where should this be applied? I'm thinking that the target RID should be calculated depending on the platform/libc types and saved to a variable or something somewhere. I just need to know where to pass the parameter in, the build or in the configure/prep step?

Also, as explained a while ago, your Prebuilt artifacts tarball will need the linux-musl-$arch variants of the platform specific nupkgs for bootstrapping. You can source them off of nuget.org without issue, just make sure to match the versions provided by the artifacts tarball.

Yeah, I already know that the musl side is going to be more of a challenge due to this and other items.

edit Of note, dotnet8 does away with non-portable Rids. Thus, void-$arch will become linux-$arch and ditto for void-musl-$arch.

Hence, another reason to calculate it ahead of time like I mentioned above. It used to be linux awhile ago and then it flipped to "void", which caught me off guard, and now it's going back. Better to define it ourselves than have it default.

[rmboggs]

If you wanna do pull requests for the staging repo to add whatever code is needed for musl/arm64, feel free. I'll pull them in and use those updates with my work and ultimate submission. I don't want to do it in the void-packages repo as they tend to do some rebasing/flattening stuff that has messed up my work before.

Or if you want to be included in this repo's org, let me know.

[ayakael]

Like so:

	./build.sh \
		-- \
		/v:n \
		/p:LogVerbosity=n \
		/p:SkipPortableRuntimeBuild=true \
                /p:TargetRid=void-musl-$arch \
                /p:AdditionalRuntimeIdentifierParent=linux-musl-$arch

By the way, SkipPortableRuntimeBuild=true doesn't do anything anymore since dotnet6.

[rmboggs]

Like so:

	./build.sh \
		-- \
		/v:n \
		/p:LogVerbosity=n \
		/p:SkipPortableRuntimeBuild=true \
                /p:TargetRid=void-musl-$arch \
                /p:AdditionalRuntimeIdentifierParent=linux-musl-$arch

Ah, in the build, good to know. Thanks.

By the way, SkipPortableRuntimeBuild=true doesn't do anything anymore since dotnet6.

Also, good to know. I'll keep that with the dotnet6 template then.

[ayakael]

As in, it only worked with dotnet5 and below, and even then it was never really supported. Aspnetcore relied on portable build artifacts. and skipping portable runtime build would thus break aspnetcore, apparently. With dotnet6, unless you use dotnet/installer#14816, you should be building runtime-portable step.

[Anachron]

Turns out, we need python (at least for cross-compiling) and this dependency was nowhere to be found in the template.

The build now fails with

≠≠≠≠                                                                                                                          
        "/usr/bin/clang-15"                                                                                                   
≠≠≠≠                                                                                                                          
      is not able to compile a simple test program.                                                                           
≠≠≠≠                                                                                                                          
      It fails with the following output:                                                                                     
≠≠≠≠                                                                                                                          
        Change Dir: '/builddir/dotnet7-7.0.110/sources/src/runtime/artifacts/source-build/self/src/artifacts/obj/coreclr/Linux
.x64.Release/CMakeFiles/CMakeScratch/TryCompile-m6dnrL'                                                                       
≠≠≠≠≠≠≠≠                                                                                                                      
        Run Build Command(s): /usr/bin/cmake -E env VERBOSE=1 /usr/bin/make -f Makefile cmTC_c98b3/fast                       
        /usr/bin/make  -f CMakeFiles/cmTC_c98b3.dir/build.make CMakeFiles/cmTC_c98b3.dir/build                                
        make[1]: Entering directory '/builddir/dotnet7-7.0.110/sources/src/runtime/artifacts/source-build/self/src/artifacts/o
bj/coreclr/Linux.x64.Release/CMakeFiles/CMakeScratch/TryCompile-m6dnrL'                                                       
        Building C object CMakeFiles/cmTC_c98b3.dir/testCCompiler.c.o                                                         
        /usr/bin/clang-15   -fstack-clash-protection -D_FORTIFY_SOURCE=2 -O2 -pipe -march=armv8-a   -I/usr/aarch64-linux-gnu/u
sr/include -ffile-prefix-map=/builddir/dotnet7-7.0.110=.  -MD -MT CMakeFiles/cmTC_c98b3.dir/testCCompiler.c.o -MF CMakeFiles/c
mTC_c98b3.dir/testCCompiler.c.o.d -o CMakeFiles/cmTC_c98b3.dir/testCCompiler.c.o -c /builddir/dotnet7-7.0.110/sources/src/runt
ime/artifacts/source-build/self/src/artifacts/obj/coreclr/Linux.x64.Release/CMakeFiles/CMakeScratch/TryCompile-m6dnrL/testCCom
piler.c                                                                                                                       
        error: unknown target CPU 'armv8-a'                                                                                   
        note: valid target CPU values are: nocona, core2, penryn, bonnell, atom, silvermont, slm, goldmont, goldmont-plus, tre
mont, nehalem, corei7, westmere, sandybridge, corei7-avx, ivybridge, core-avx-i, haswell, core-avx2, broadwell, skylake, skyla
ke-avx512, skx, cascadelake, cooperlake, cannonlake, icelake-client, rocketlake, icelake-server, tigerlake, sapphirerapids, al
derlake, knl, knm, k8, athlon64, athlon-fx, opteron, k8-sse3, athlon64-sse3, opteron-sse3, amdfam10, barcelona, btver1, btver2
, bdver1, bdver2, bdver3, bdver4, znver1, znver2, znver3, x86-64, x86-64-v2, x86-64-v3, x86-64-v4                             
        make[1]: *** [CMakeFiles/cmTC_c98b3.dir/build.make:79: CMakeFiles/cmTC_c98b3.dir/testCCompiler.c.o] Error 1           
        make[1]: Leaving directory '/builddir/dotnet7-7.0.110/sources/src/runtime/artifacts/source-build/self/src/artifacts/ob
j/coreclr/Linux.x64.Release/CMakeFiles/CMakeScratch/TryCompile-m6dnrL'                                                        
        make: *** [Makefile:127: cmTC_c98b3/fast] Error 2   

I think I will move this one on my aarch64 NAS later and try a native build there. Stay tuned.

[ayakael]

Turns out, we need python (at least for cross-compiling) and this dependency was nowhere to be found in the template.

The build now fails with

≠≠≠≠                                                                                                                          
        "/usr/bin/clang-15"                                                                                                   
≠≠≠≠                                                                                                                          
      is not able to compile a simple test program.                                                                           
≠≠≠≠                                                                                                                          
      It fails with the following output:                                                                                     
≠≠≠≠                                                                                                                          
        Change Dir: '/builddir/dotnet7-7.0.110/sources/src/runtime/artifacts/source-build/self/src/artifacts/obj/coreclr/Linux
.x64.Release/CMakeFiles/CMakeScratch/TryCompile-m6dnrL'                                                                       
≠≠≠≠≠≠≠≠                                                                                                                      
        Run Build Command(s): /usr/bin/cmake -E env VERBOSE=1 /usr/bin/make -f Makefile cmTC_c98b3/fast                       
        /usr/bin/make  -f CMakeFiles/cmTC_c98b3.dir/build.make CMakeFiles/cmTC_c98b3.dir/build                                
        make[1]: Entering directory '/builddir/dotnet7-7.0.110/sources/src/runtime/artifacts/source-build/self/src/artifacts/o
bj/coreclr/Linux.x64.Release/CMakeFiles/CMakeScratch/TryCompile-m6dnrL'                                                       
        Building C object CMakeFiles/cmTC_c98b3.dir/testCCompiler.c.o                                                         
        /usr/bin/clang-15   -fstack-clash-protection -D_FORTIFY_SOURCE=2 -O2 -pipe -march=armv8-a   -I/usr/aarch64-linux-gnu/u
sr/include -ffile-prefix-map=/builddir/dotnet7-7.0.110=.  -MD -MT CMakeFiles/cmTC_c98b3.dir/testCCompiler.c.o -MF CMakeFiles/c
mTC_c98b3.dir/testCCompiler.c.o.d -o CMakeFiles/cmTC_c98b3.dir/testCCompiler.c.o -c /builddir/dotnet7-7.0.110/sources/src/runt
ime/artifacts/source-build/self/src/artifacts/obj/coreclr/Linux.x64.Release/CMakeFiles/CMakeScratch/TryCompile-m6dnrL/testCCom
piler.c                                                                                                                       
        error: unknown target CPU 'armv8-a'                                                                                   
        note: valid target CPU values are: nocona, core2, penryn, bonnell, atom, silvermont, slm, goldmont, goldmont-plus, tre
mont, nehalem, corei7, westmere, sandybridge, corei7-avx, ivybridge, core-avx-i, haswell, core-avx2, broadwell, skylake, skyla
ke-avx512, skx, cascadelake, cooperlake, cannonlake, icelake-client, rocketlake, icelake-server, tigerlake, sapphirerapids, al
derlake, knl, knm, k8, athlon64, athlon-fx, opteron, k8-sse3, athlon64-sse3, opteron-sse3, amdfam10, barcelona, btver1, btver2
, bdver1, bdver2, bdver3, bdver4, znver1, znver2, znver3, x86-64, x86-64-v2, x86-64-v3, x86-64-v4                             
        make[1]: *** [CMakeFiles/cmTC_c98b3.dir/build.make:79: CMakeFiles/cmTC_c98b3.dir/testCCompiler.c.o] Error 1           
        make[1]: Leaving directory '/builddir/dotnet7-7.0.110/sources/src/runtime/artifacts/source-build/self/src/artifacts/ob
j/coreclr/Linux.x64.Release/CMakeFiles/CMakeScratch/TryCompile-m6dnrL'                                                        
        make: *** [Makefile:127: cmTC_c98b3/fast] Error 2   

I think I will move this one on my aarch64 NAS later and try a native build there. Stay tuned.

Indeed, cross-compiling dotnet is... not straightforward. For Alpine we had to ditch source-build and crosscompile individual components: https://lab.ilot.io/ayakael/dotnet-stage0/-/blob/main/APKBUILD

I'd keep it native, and use the binaries provided by Microsoft for now.

[IcedQuinn]

Downloading the binaries and running them from the folder they come in seems to work for now.

They imply you can have multiple SDKs and runtimes available and callable from the same dotnet. Not sure how that works though.

[rmboggs]

I'm moving this conversation over to:
#3

Seems more appropriate there now.