Is it expected that cli can be built on ARM?

[DanTup]

I was under the impression that I could build this on ARM (as is @shanselman), however I've been unable to make it work. The first step of build.sh seems to be to download a binary rather than build and that seems to be an x86 binary.

I found #5310 but it's not clear it that was about binaries or building from source (it sounds like the poster was trying to build, but the subject suggests he wanted binaries).

Is it supposed to be possible to build on ARM, or is this also unsupported?

Steps to reproduce

1. Clone repo on Arm machine (eg. Raspberry Pi)
2. Execute build.sh

Expected behavior

Build with no errors.

Actual behavior

Error when executing dotnet restore

Environment data

dotnet --info output:
dotnet does not run

[TheRealPiotrP]

The CLI itself is a portable application, so it will run happily anywhere we find a CLR, CoreFx, and Host [Shared Framework] to match. Whenever we do a new platform bring-up there is a one-time step to bootstrap builds. We've historically done this by getting the Host [corehost] to build, taking a corresponding CLR + CoreFx, and manually building out the first drop of the CLI. Afterwards, the system rolls forward nicely.

We don't have any immediate plans to expand platform coverage. That said, if this is blocking you and you are interested in submitting a PR then I can see if/how soon we could stand up a CI to match.

[DanTup]

It's not a big deal, I just thought it'd be fun to get it up and running on my Pi. I'm not sure if I know enough about Linux (total noob!) or dotnet core to do much without hand-holding :(

[frodestorhaug]

It would be very nice to be able to build CLI for ARM and Raspberry pi. We have several projects where we are using rc1 on Pi, and it would be excellent to be able to try rc2

[shanselman]

@moozzyk was able to build it a while back. I still need to get him his Raspberry Pi back, in fact.

[moozzyk]

I was actually thinking about trying to enable dotnet on ARM... CoreClr on ARM works and the cli itself does not have a lot awful of native code.

[DanTup]

I'm slightly confused from the last two comments about whether this is possible or needs work? :/

@piotrpMSFT said the CLI is a portable app, but @moozzyk said it has some native code.

(it's possible I'm confused between the terms dotnet/cli/coreclr/etc.!)

[moozzyk]

@DanTup - the lowest layer of the code/bootstrapper is native and CoreClr has also a lot of native code. Currently there is no version of the bootstrapper that is compiled for ARM. The CLI portable applications can be run on different platforms as long as there is a bootstrapper and CoreClr for a given platform.

[DanTup]

Sorry, still confused :( What was it that you got working with Scott?

Currently there is no version of the bootstrapper that is compiled for ARM.

Could I just compile the whole thing directly on a Pi or would it likely need debugging/tweaking of native code?

[synercoder]

I am also working with my Raspberry Pi's to try to get dotnet working on them. I have RPi 2 and RPi 3. I have been tinkering with both Raspian Jessie and Windows 10 IoT core. I have yet to gain some results, but i'll keep tinkering.

[olliholliday]

I'm using PI2s with mono rc2 and dnx4.5.1 on raspbian jessie at the moment and it's all great, I'm interested in knowing what my options are going forwards though. I'd like to be able to use the new stuff in future. Stuck with linux as I need hardware accelerated display.

It's out of my comfort zone to try it myself but, if needed, I'd be a willing tester / experimenter for somebody wanting to have a crack.

[shahid-pk]

coreclr has made very good progress on linux arm , thanks to contributions from the community. People from the community are tracking the progress here.
https://github.com/dotnet/coreclr/issues/3977

I think manually building coreclr on arm and using that build to built this repo can be made possible. But i think to make cli functional on linux will also need some changes to corefx, mainly publishing linux arm version of native bits published to the nuget feeds.

The actual native code work required was in coreclr which is very near to complete as can be seen from the arm progress issue i linked.

[myungjoo]

@mylibero had "almost" prepared dotnet-cli/ARM a while ago to the point where we simply need to run Roslyn(csc.exe) in ARM/Linux, which seems to run reliably now (I build my own ARM/Linux c# test cases in ARM machines).

[SteveDesmond-ca]

Is the source available for this "stage0" bootstrapper? Obviously there's a bit of inception going on, since the bootstrapper itself is a dotnet CLI, so I'm not sure if it's just a previous build of the full dotnet CLI, or something else but just named the same.

Alternatively, might be able to work some magic with qemu...

[petergloor]

I've recently noticed an increasing demand for C# support on Raspbian Jessie. .NET Core would provide a great framework for many kind of networked applications.

[DanTup]

I've recently noticed an increasing demand for C# support on Raspbian Jessie

I tried using Mono for now because of lack of support for Core but it was so clunky/buggy and installed so much junk on my Pi I've recently just abandoned the idea of using C# and converted my scripts to Dart. Dart runs on my PC, my x86 Chromebook (in Dev mode, without needing a full linux install) and my Pi; that's what I call cross-platform (.NET Core won't currently run on either the CB or the Pi). :-(

[krontogiannis]

👍
Having .NET Core on Raspbian would be great. Using mono with it's asp.net implementation feels too clunky. Running asp.net core with mono, i'm not even sure if it's possible at the moment (getting the full stack to work: mvc, razor, webapi).

[SteveDesmond-ca]

Glad this is starting to get some traction -- my qemu hail mary hit a dead end and now that I have an ARM Chromebook, I need this more than ever!

While officially this is on the roadmap for Q4'16/Q1'17, I'd love to get it working on a dev branch ASAP...If it's simply a matter of priority, I have the cycles to help out however I can -- just point me in the direction of how you'd like it to work and I'll see what I can do about a PR!

Otherwise, my next hail mary is going to be to fork dnx as the stage0...

[shahid-pk]

for stage0 one will need to compile dotnet/coreclr and corefx for pi2 (which is quite stable now) and use that build to run other stages which i suppose includes running nuget for restore , and csc for compiling and may be msbuild too. All of these can be made to run on a coreclr and corefx build as the cli uses nuget to download packages and csc to compile source code.

[cydhaselton]

From @piotrpMSFT

The CLI itself is a portable application, so it will run happily anywhere we find a CLR, CoreFx, and Host [Shared Framework] to match.

I found this after cloning the cli repo to my Android device...which I did after successfully building CoreCLR and CoreFX. I have two questions and one request:

1. Am I correct in understanding that dotnet/cli cannot be built on unsupported platforms because corehost needs to be manually built?
2. If the answer is "yes", could the build from source instructions...i.e. the prerequisites... be updated to include this? Right now it says that all that's needed to build dotnet/cli is CMake, git and clang.
3. If the answer is no...could we get a little more detail into what is necessary to build dotnet/cli from sources? If there are other dotnet components that are prerequisites, please include those.

[SteveDesmond-ca]

If I'm not mistaken, corehost is no longer, so how would we do this now? (other than going back to the last commit before corehost was removed, unless that's the only way)

[SteveDesmond-ca]

Just discovered corehost got moved to https://github.com/dotnet/core-setup -- hopefully can make some more progress now

[moljac]

I'm confused with dependencies...
How can dotnet be built? Seems like it is used to build all repos except coreclr.

(BananaPi + Ubuntu)

Namely I managed to compile coreclr, but

corefx downloads dotnet.tar with x86/x64 binaries:

Installing dotnet cli... __DOTNET_LOCATION = https://dotnetcli.blob.core.windows.net/dotnet/Sdk/1.0.0-preview3-003223/dotnet-dev-ubuntu.16.04-x64.1.0.0-preview3-003223.tar.gz

So, I assume cli is needed as next, but this repo downloads dotnet too:

`
dotnet-install: Calling: machine_has curl
dotnet-install: Calling: calculate_vars
dotnet-install: Calling: get_azure_channel_from_channel rel-1.0.0
dotnet-install: azure_channel=rel-1.0.0
dotnet-install: Calling: get_normalized_architecture_from_architecture
dotnet-install: Calling: get_machine_architecture
dotnet-install: Calling: get_normalized_architecture_from_architecture x64
dotnet-install: normalized_architecture=x64
dotnet-install: Calling: get_specific_version_from_version https://dotnetcli.azureedge.net/dotnet rel-1.0.0 x64 Latest
dotnet-install: Calling: get_latest_version_info https://dotnetcli.azureedge.net/dotnet rel-1.0.0 x64
dotnet-install: Calling: get_current_os_name
dotnet-install: get_latest_version_info: latest url: https://dotnetcli.blob.core.windows.net/dotnet/Sdk/rel-1.0.0/latest.version
dotnet-install: Calling: download https://dotnetcli.blob.core.windows.net/dotnet/Sdk/rel-1.0.0/latest.version
dotnet-install: get_specific_version_from_version: version_info=038fb6fbae39594abc97b7c3f66f8ab20182daa9
1.0.0-preview3-003686
dotnet-install: Calling: get_version_from_version_info
dotnet-install: specific_version=1.0.0-preview3-003686
dotnet-install: Calling: construct_download_link https://dotnetcli.azureedge.net/dotnet rel-1.0.0 x64 1.0.0-preview3-003686
dotnet-install: Calling: get_current_os_name
dotnet-install: download_link=https://dotnetcli.azureedge.net/dotnet/Sdk/1.0.0-preview3-003686/dotnet-dev-ubuntu.16.04-x64.1.0.0-preview3-003686.tar.gz
dotnet-install: Calling: resolve_installation_path
dotnet-install: Calling: get_user_share_path
dotnet-install: resolve_installation_path: share_path=/root/holisticware/cli/.dotnet_stage0/x64
dotnet-install: install_root=/root/holisticware/cli/.dotnet_stage0/x64
dotnet-install: Calling: check_pre_reqs
dotnet-install: Calling: install_dotnet
dotnet-install: Calling: is_dotnet_package_installed /root/holisticware/cli/.dotnet_stage0/x64 sdk 1.0.0-preview3-003686
dotnet-install: Calling: combine_paths /root/holisticware/cli/.dotnet_stage0/x64 sdk
dotnet-install: combine_paths: root_path=/root/holisticware/cli/.dotnet_stage0/x64
dotnet-install: combine_paths: child_path=sdk
dotnet-install: Calling: combine_paths /root/holisticware/cli/.dotnet_stage0/x64/sdk 1.0.0-preview3-003686
dotnet-install: combine_paths: root_path=/root/holisticware/cli/.dotnet_stage0/x64/sdk
dotnet-install: combine_paths: child_path=1.0.0-preview3-003686
dotnet-install: is_dotnet_package_installed: dotnet_package_path=/root/holisticware/cli/.dotnet_stage0/x64/sdk/1.0.0-preview3-003686
is already installed.DK version 1.0.0-preview3-003686
dotnet-install: Calling: combine_paths /root/holisticware/cli/.dotnet_stage0/x64
dotnet-install: combine_paths: root_path=/root/holisticware/cli/.dotnet_stage0/x64
dotnet-install: combine_paths: child_path=
dotnet-install: Calling: get_absolute_path /root/holisticware/cli/.dotnet_stage0/x64/
dotnet-install: Adding to current process PATH: /root/holisticware/cli/.dotnet_stage0/x64. Note: This change will be visible only when sourcing script.
dotnet-install: Installation finished successfully.
Tools are already initialized

/root/holisticware/cli/run-build.sh: line 120: /root/holisticware/cli/.dotnet_stage0/x64/dotnet: cannot execute binary file: Exec format error
`

while core-setup downloads:

dotnet-install: Downloading https://dotnetcli.blob.core.windows.net/dotnet/preview/Binaries/1.0.0-preview2-003133/dotnet-dev-ubuntu.16.04-x64.1.0.0-preview2-003133.tar.gz

[brunobertechini]

+1 for arm devices (not only raspberry pi). Will cross-compiling work ? I.e. build on a linux machine with crosscompilling toolchain and then copy binaries to linux arm device?

[cydhaselton]

So did anyone locate the sources for the dotnet binary?

[blackdwarf]

@cydhaselton

So did anyone locate the sources for the dotnet binary?

If by "dotnet binary" you mean the muxer, the source is in https://github.com/dotnet/core-setup.

[SteveDesmond-ca]

Yeah, ARM builds are actually pretty close -- see dotnet/core-setup#725 for details

[hqueue]

FYI. "dotnet" muxer, CoreCLR and CoreFX for ARM is now available as described in https://github.com/dotnet/core-setup/issues/725. However you still have to build them yourself with cross compilation by now.
In addition, you may need CLI running on ARM to build CLI itself and it is being discussed at dotnet/cli#5289 .

[cydhaselton]

Yeah, ARM builds are actually pretty close -- see dotnet/core-setup#725 for details

I'm actively working on bringing up Android/ARM64 based on that checklist and, while it is useful I'm still a bit fuzzy on the relationship between core-setup and cli, and what both repos contain. I understand that core-setup contains the installer bits for CoreFX, CoreCLR and shared host (dotnet) but the installation scenarios link points to documentation in the cli repo and seems to about installation of the CLI. If I go to the home page for the CLI repo, I see that it's the source for the .NET Core command-line toolchain, but not really because a link in that page points to the various separate repos that make up .NET Core.

Right now I'm trying to figure out if CLI will be needed as part of Android/ARM64 enablement and, if so, is it a prerequisite to bringing up core-setup or not.

After this post I'll be reading the What Is .NET Core link because I assume it will help me get a handle on the various moving parts and know what is needed to bring up a new platform, but I could use suggestions/recommendations.

[omajid]

@cydhaselton The way I understand .NET Core components and how they map to repositories is as follows:

• .NET Core Shared Runtime is a combination of dotnet/corefx and dotnet/coreclr
• Muxer/host selects which runtime to run and is basically dotnet/core-setup
• .NET Core SDK provides the tools for building code and is essentially dotnet/cli which in-turn includes dotnet/sdk and muxer and runtime

[cydhaselton]

Note to others working on new platform bring up, dotnet/coreclr#917 is an ongoing discussion.

[SteveDesmond-ca]

@cydhaselton The CLI is for doing things like dotnet new, dotnet restore, dotnet build, dotnet run, etc. I tried to describe these in my blog post on the topic.

In my experimentation, the CLI commands were all far too slow on ARM to be useful, so I have stopped working on getting the CLI buildable for ARM.

While it is possible to build and develop from an ARM device, I see ARM much more realistically solely as a build target. Just as you wouldn't develop or build Android or iPhone apps on the devices you're targeting, you'd build your .NET Core app on a proper (x64) development environment, targeting ARM, and then deploy it to ARM devices.

[cydhaselton]

@SteveDesmond-ca: Thanks for the clarification. A few follow up questions:

1. How would such a build target fit into the current pipeline? Or should there be a separate pipeline for build targets? What would be the steps for bootstrapping an unsupported platform as a new build target?
2. While phone development would be cumbersome, tablet development...i.e. on-tablet development...is definitely a "thing" given the availability of on-device IDEs available in Google Play. Would bootstrapping an Android platform follow the same steps as for Alpine Linux? Are there any breaking constraints (space limitations for example) for doing so?

[SteveDesmond-ca]

1. I think the stuff in dotnet/core-setup#725 covers that. I have heard from multiple sources recently (@bleroy? @DamianEdwards?) there's also work being done to make onboarding new targets easier, e.g. a generic Linux RID instead of different ones for each distro, so not sure if that will help simplify what you're looking for as well.
2. I can definitely relate -- I'd love to be able to develop .NET from my Chromebook as well, but when "Hello World" takes a full minute to compile there, it's just doesn't seem feasible right now. I think the SDK (and maybe even Roslyn?) would need some pretty major perf review to get it in shape for low-end hardware to be considered reasonable build hosts. Maybe since this is considered post-2.0, it can be more of a priority...haven't checked the roadmap lately.

[cydhaselton]

I think the stuff in dotnet/core-setup#725 covers that. I have heard from multiple sources recently (@bleroy? @DamianEdwards?) there's also work being done to make onboarding new targets easier, e.g. a generic Linux RID instead of different ones for each distro, so not sure if that will help simplify what you're looking for as well.

Two or more of the tasks in dotnet/core-setup#725 involve cross-building corehost and/or dotnet for the target. If we're creating a build target, rather than a full deployment, wouldn't those steps be excluded? If so, would the final "package" be affected?

[ydanila]

Does current build.sh could be used to create arm binaries?

First I have error linked with distributive:
dotnet_install: Error: OS name could not be detected: ubuntu.17.04
Second - build script calls dotnet-install.sh for x64
/root/sdk/cli/scripts/obtain/dotnet-install.sh --channel master --version 2.0.0-preview1-005867 --install-dir /root/sdk/cli/.dotnet_stage0/x64 --architecture x64

[SteveDesmond-ca]

There are ARM builds of the .NET Core Runtime at https://github.com/dotnet/core-setup, but (unless something has stealthily changed) the CLI/SDK is still x64 only.

[livarcocc]

we now have linux arm32 and linux arm64 un-official builds available with 2.1.300 CLI.

[verysimplenick]

@livarcocc good news, how we can build for linux-arm64 (I want run on arm64v8) ?
I tried run dotnet publish -c Release -r linux-arm64on 2.1.300-preview3-008424 - without success.

[livarcocc]

what failure did you see? cross publishing should be supported independent of having a .NET Core SDK that targets that or not. For instance, I can publish to linux from a windows box without any issues. In that sense, publishing to linux-arm should be no different.

@Petermarcu what is the appropriate rid for linux arm64?

[Petermarcu]

Thats the right rid but @eerhardt made an update in corefx to add it to the identity package. I don't know if he fix has flowed into the SDK yet.

I had to explicitly reference the runtime packages because the link up wasn't in there. I also had to disable package dependency validation. Here is a sample of the workaround:

<Project Sdk="Microsoft.NET.Sdk">

  <PropertyGroup>
    <OutputType>Exe</OutputType>
    <TargetFramework>netcoreapp2.1</TargetFramework>
    <RuntimeFrameworkVersion>2.1.0-preview3-26326-02</RuntimeFrameworkVersion>
    <EnsureRuntimePackageDependencies>false</EnsureRuntimePackageDependencies>
  </PropertyGroup>

  <ItemGroup>
    <PackageReference Include="runtime.linux-arm64.Microsoft.NETCore.App" Version="2.1.0-preview3-26326-02" />
    <PackageReference Include="runtime.linux-arm64.Microsoft.NETCore.DotNetAppHost" Version="2.1.0-preview3-26326-02" />
    <PackageReference Include="runtime.linux-arm64.Microsoft.NETCore.DotNetHostResolver" Version="2.1.0-preview3-26326-02" />
    <PackageReference Include="runtime.linux-arm64.Microsoft.NETCore.DotNetHostPolicy" Version="2.1.0-preview3-26326-02" />
  </ItemGroup>

</Project>

You will need to adjust the versions as appropriate and make sure you have a nuget.config.

<?xml version="1.0" encoding="utf-8"?>
<configuration>
  <packageSources>
    <add key="dotnet-core" value="https://dotnet.myget.org/F/dotnet-core/api/v3/index.json" />
  </packageSources>
</configuration>

[verysimplenick]

@Peter-Schneider , @livarcocc
Ok, publishing now is fine, now I try run on my router published app:
dotnet hello_world.dll

A fatal error was encountered. The library 'libhostpolicy.so' required to execute the application was not found in '/tmp/mnt/sda1/dotnet/hello_world/'.
Failed to run as a standalone app. If this should be a portable app, specify the appropriate framework in /tmp/mnt/sda1/dotnet/hello_world/hello_world.runtimeconfig.json.

# ldd ./hello_world

        linux-vdso.so.1 (0x0000007fb0f89000)
        libdl.so.2 => /lib/aarch64/libdl.so.2 (0x0000007fb0f4b000)
        libpthread.so.0 => /lib/aarch64/libpthread.so.0 (0x0000007fb0f1f000)
        libstdc++.so.6 => /tmp/mnt/sda1/dotnet/libstdc++.so.6 (0x0000007fb0dcf000)
        libm.so.6 => /lib/aarch64/libm.so.6 (0x0000007fb0d2c000)
        libgcc_s.so.1 => /tmp/mnt/sda1/dotnet/libgcc_s.so.1 (0x0000007fb0d0c000)
        libc.so.6 => /lib/aarch64/libc.so.6 (0x0000007fb0bc2000)
        /lib/ld-linux-aarch64.so.1 (0x0000007fb0f5e000)

echo $LD_LIBRARY_PATH

:/tmp/mnt/sda1/dotnet/:/tmp/mnt/sda1/dotnet/shared/Microsoft.NETCore.App/2.1.0-preview3-26326-02

Whats wrong?

[livarcocc]

Are you xcopying the contents of the publish folder? Under something like bin\debug\netcoreapp2.0\publish? That's what you need to copy, not the contents under the build folder.

[verysimplenick]

@livarcocc yes, I had tried run under publish (bin\Release\netcoreapp2.1\linux-arm64\publish\)

[Petermarcu]

Ah, typo in my sample. Sorry. The last package is missing "64" it needs to be runtime.linux-arm64.Microsoft.NETCore.DotNetHostPolicy. Thats the missing file.

[Petermarcu]

I'm fixing my example inline as well.

[verysimplenick]

@Petermarcu 🥇 , @livarcocc 🥇 Thanks, finally run hello world on arm64v8 router :)