Fix building on ARMhf userland on top of AARCH64 kernel #97929
Conversation
ghost
added
the
community-contribution
|
Tagging subscribers to this area: @dotnet/area-infrastructure-libraries Issue DetailsRaspberry Pi 4/5 supports running 32-bit Linux with a 64-bit kernel. Detect that and install linux-arm version of .NET instead of linux-arm64. The arm64 version doesn't work in that scenario. Should I submit the relevant bits as dotnet/arcade PR?
|
|
Tagging subscribers to this area: @dotnet/runtime-infrastructure Issue DetailsRaspberry Pi 4/5 supports running 32-bit Linux with a 64-bit kernel. Detect that and install linux-arm version of .NET instead of linux-arm64. The arm64 version doesn't work in that scenario. Should I submit the relevant bits as dotnet/arcade PR? Related: dotnet/install-scripts#435
|
Yes, anything that goes in eng/common needs to be added there so the next arcade sync PR doesn't overwrite the changes.
Is it so that we supported this configuration at some point which is now broken? AFAIK, we never supported things like 32-bit unix process on 64 bit machine ( |
I'll submit dotnet/arcade PR when I get back to my machine on Monday.
There were definitely some attempts to support it (dotnet/arcade#13392). I think this configuration is slightly more common than the x86/x64 mix. Raspberry Pi installer still offers it as one of the options in the official installer. Moreover, it happens to automatically choose the kernel based on the hardware, so if you swap an SD card from older Raspberry Pi into a new one you may end up with 64-bit kernel. Raspberry Pi 5 started ignoring the |
There are few differences:
Yup, if all it takes is adding missing pieces in shell/cmake configurations, sounds like we should go for it. My hunch was supporting these configurations would require updating coreclr-pal as well (among other things), so this maybe the tip of iceberg. I don't mean to demotivate, just a heads-up; there may be possible dragons. :) |
This is very different from the x32 or emulation scenarios. The whole user land here is standard ARMhf compiled binaries, instructions, ABI and everything, only the kernel is different. You cannot even run aarch64 binaries because there are no user land libraries to support that. The only problem is detection using I have been running this configuration for a week with both CoreCLR and NativeAOT builds, incl. test runs. I don’t expect (many) dragons ahead. In fact, the current off-the-shelf behavior on this system is that the build downloads linux-arm64 dotnet which cannot run, so it fails right away. |
Yup, that's what I was trying to cover in third bullet.
Nice! In that case, LGTM. :) |
eng/native/init-os-and-arch.sh
Outdated
| @@ -35,6 +35,10 @@ fi | |||
| case "$CPUName" in | |||
There was a problem hiding this comment.
it would be nice to remove this script now that we have it in eng/common
There was a problem hiding this comment.
I will check if we can remove the extra copy.
Similarly, any thoughts about the dotnet-install.sh copy? It’s not used at the moment.
There was a problem hiding this comment.
eng/common/dotnet-install.sh is used by eng/common/tools.sh.
There was a problem hiding this comment.
It's not used by the top-level dotnet.sh which bit me quite a bit.
There was a problem hiding this comment.
On second look, the top-level dotnet.sh references eng/common/tools.sh which in turn downloads the official dotnet-install.sh from web.
There was a problem hiding this comment.
It's conditional on -a (if path exists) in tools.sh, so not unused. Maybe it is there for SB offline mode or some other repo use-case (like dotnet/arcade#14283), so leave it for now as out of PR scope? init-os-and-arch is definitely something we can dedup (as it was the plan dotnet/arcade#13947). It can also be cleaned up as a separate PR.
There was a problem hiding this comment.
It's conditional on -a (if path exists) in tools.sh, so not unused.
The $root path it checks is outside of eng/common normally though (e.g. in runtime we install the local dotnet into <repo root>/.dotnet) so the copy in common won't be used by tools.sh.
It is used by the Arcade msbuild targets to install dotnet: https://github.com/dotnet/arcade/blob/2fb543a45580400a559b5ae41c96a815ea14dac5/src/Microsoft.DotNet.Arcade.Sdk/tools/InstallDotNetCore.targets#L6-L11
There was a problem hiding this comment.
I guess that begs a question... shouldn't it be used? (not going to resolve it in this PR, just asking)
There was a problem hiding this comment.
No idea. From a quick look the eng/common/dotnet-install.sh is much simpler than the one from https://dot.net/v1/dotnet-install.sh, that was probably intentional?
|
Could you please resolve the conflict? |
Yep, just working on it. |
filipnavara
force-pushed
the
armhf-userland
branch
from
a0d42e6 to
d573365
Compare
Raspberry Pi 4/5 supports running 32-bit user land with a 64-bit Linux kernel. Detect that and install linux-arm version of .NET instead of linux-arm64. The arm64 version doesn't work in that scenario.
Should I submit the relevant bits as dotnet/arcade PR?
Related: dotnet/install-scripts#435