New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Is it expected that cli can be built on ARM? #2556

Closed
DanTup opened this Issue Apr 18, 2016 · 46 comments

Comments

Projects
None yet
@DanTup

DanTup commented Apr 18, 2016

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 #1730 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
Build failing
Failing line and file info of dotnet

Environment data

dotnet --info output:
dotnet does not run

@TheRealPiotrP TheRealPiotrP added this to the Backlog milestone Apr 18, 2016

@TheRealPiotrP

This comment has been minimized.

Contributor

TheRealPiotrP commented Apr 18, 2016

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

This comment has been minimized.

DanTup commented Apr 18, 2016

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

This comment has been minimized.

frodestorhaug commented Apr 28, 2016

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

This comment has been minimized.

Contributor

shanselman commented May 6, 2016

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

@moozzyk

This comment has been minimized.

Contributor

moozzyk commented May 6, 2016

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

This comment has been minimized.

DanTup commented May 7, 2016

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

This comment has been minimized.

Contributor

moozzyk commented May 9, 2016

@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

This comment has been minimized.

DanTup commented May 9, 2016

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

This comment has been minimized.

synercoder commented May 10, 2016

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

This comment has been minimized.

olliholliday commented May 10, 2016

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

This comment has been minimized.

Contributor

shahid-pk commented May 10, 2016

coreclr has made very good progress on linux arm , thanks to contributions from the community. People from the community are tracking the progress here.
dotnet/coreclr#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

This comment has been minimized.

myungjoo commented May 13, 2016

@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

This comment has been minimized.

Contributor

stevedesmond-ca commented Jun 19, 2016

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

This comment has been minimized.

petergloor commented Aug 17, 2016

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

This comment has been minimized.

DanTup commented Aug 17, 2016

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

This comment has been minimized.

krontogiannis commented Aug 17, 2016

👍
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

This comment has been minimized.

Contributor

stevedesmond-ca commented Aug 17, 2016

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

This comment has been minimized.

Contributor

shahid-pk commented Aug 17, 2016

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

This comment has been minimized.

cydhaselton commented Sep 7, 2016

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

This comment has been minimized.

Contributor

stevedesmond-ca commented Sep 9, 2016

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

This comment has been minimized.

Contributor

stevedesmond-ca commented Sep 14, 2016

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

@moljac

This comment has been minimized.

moljac commented Sep 25, 2016

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

This comment has been minimized.

brunobertechini commented Oct 20, 2016

+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

This comment has been minimized.

cydhaselton commented Oct 24, 2016

So did anyone locate the sources for the dotnet binary?

@blackdwarf

This comment has been minimized.

Contributor

blackdwarf commented Jan 15, 2017

@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

This comment has been minimized.

Contributor

stevedesmond-ca commented Jan 15, 2017

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

@hqueue

This comment has been minimized.

Member

hqueue commented Jan 16, 2017

FYI. "dotnet" muxer, CoreCLR and CoreFX for ARM is now available as described in dotnet/core-setup#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 #5289 .

@cydhaselton

This comment has been minimized.

cydhaselton commented Mar 19, 2017

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

This comment has been minimized.

Member

omajid commented Mar 20, 2017

@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

This comment has been minimized.

cydhaselton commented Mar 20, 2017

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

@stevedesmond-ca

This comment has been minimized.

Contributor

stevedesmond-ca commented Mar 20, 2017

@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

This comment has been minimized.

cydhaselton commented Mar 20, 2017

@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

This comment has been minimized.

Contributor

stevedesmond-ca commented Mar 20, 2017

  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

This comment has been minimized.

cydhaselton commented Mar 20, 2017

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

This comment has been minimized.

ydanila commented Jun 1, 2017

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

This comment has been minimized.

Contributor

stevedesmond-ca commented Jun 1, 2017

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

This comment has been minimized.

Member

livarcocc commented Mar 27, 2018

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

@livarcocc livarcocc closed this Mar 27, 2018

@verysimplenick

This comment has been minimized.

verysimplenick commented Mar 29, 2018

@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

This comment has been minimized.

Member

livarcocc commented Mar 29, 2018

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

This comment has been minimized.

Member

Petermarcu commented Mar 29, 2018

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

This comment has been minimized.

verysimplenick commented Mar 29, 2018

@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

This comment has been minimized.

Member

livarcocc commented Mar 30, 2018

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

This comment has been minimized.

verysimplenick commented Mar 30, 2018

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

@Petermarcu

This comment has been minimized.

Member

Petermarcu commented Mar 30, 2018

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

This comment has been minimized.

Member

Petermarcu commented Mar 30, 2018

I'm fixing my example inline as well.

@verysimplenick

This comment has been minimized.

verysimplenick commented Mar 30, 2018

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment