Need to build core-setup for `linux-arm`

[eerhardt]

We currently have linux-x64 and ubuntu.xx.yy-arm, but we don't have a portable linux-arm build yet.

We need to get Jenkins and official builds for this new runtime.

/cc @gkhanna79

[Petermarcu]

@janvorli started looking that that.

[gkhanna79]

CoreCLR started to produce linux-arm since yesterday. I am in the process of transitioning all repos to do the same - @Petermarcu what is @janvorli working upon? I want to make sure we are not doing the same thing.

[gkhanna79]

Here is the package in question - https://dotnet.myget.org/feed/dotnet-core/package/nuget/runtime.linux-arm.Microsoft.NETCore.Runtime.CoreCLR

[Petermarcu]

he was just making sure that there weren't any blockers in building that way. I dont think he was actually hooking it all up.

[gkhanna79]

he was just making sure that there weren't any blockers in building that way

I believe this was validated sometime ago, no?

[Petermarcu]

yeah

[JensNordenbro]

Is this to enable all native binaries to be compatible cross the different Linux-distributions @eerhardt, hence eliminating the need for different linux-arm-RIDs in the long run or is it more of an internal thing?

[eerhardt]

Yes, this is for all native binaries to be compatible cross the different Linux distros. This isn't an internal thing. We are already producing linux-arm for coreclr and corefx repos. We just need to use those packages and build linux-arm packages for core-setup.

See

https://dotnet.myget.org/feed/dotnet-core/package/nuget/runtime.linux-arm.Microsoft.NETCore.Runtime.CoreCLR https://dotnet.myget.org/feed/dotnet-core/package/nuget/runtime.linux-arm.Microsoft.Private.CoreFx.NETCoreApp

[JensNordenbro]

Thanks @eerhardt . This sounds nice! Just to get a better feeling for what this will mean in the long run; am I right in that this will:

1. Help me as a Nuget producer to target Linux-ARM as long as I only target .net standard for the managed parts and for the native parts target glibc. Basically I will need to build and publish for each CPU-architecture,
2. Help me supporting CoreClr on meta distributions like Yocto where the "root-fs" is much more dynamic than on fixed-dists like Ubuntu and the prospect of using Nugets struggles today.
3. This will help CoreRT to produce "portable" ARM compiled binaries.

..or am I hoping for too much? :)

[gkhanna79]

With linux-arm in picture, you would be able to publish your application for any linux distribution that is glibc based (we will define the minimum supported version). Ofcourse, the assumption is that any native artifacts that conform to linux-arm follow similar rules of minimum supported version for linkages.

Once the above is done, the app should work on my glibc based Linux >= minimum supported version.

This has nothing to do with CoreRT :)

[JensNordenbro]

@gkhanna79 , I take that as a yes to question 1 and 2, provided fullfilment of native dependencies . That is really nice to see and will help a lot!!

Just out of curiosity, I was under the impression that corert and coreclr are related(at least jit-based aot), also that they share corefx; therefor I assumed this work also would help enable cross building to linux-arm profile for corert builds in the future, but maybe it is more complex than that:-)

[gkhanna79]

at least jit-based aot

This is a current implementation detail for CoreRT. In future, it could use any code generator (or we could choose to change the codegenerator). However, this only impacts generated code and not the linkages introduced in sections like IAT.

Targeting a general purpose Arm profile is really about ensuring that your dependencies are either minimum such that all supported platforms have it OR you can get to them dynamically. For .NET Core 2.0, we have chosen the latter since we cannot be in the former category for design/feature reasons.

[JensNordenbro]

ok @gkhanna79 . thanks for the info!

[gkhanna79]

Closing as this is complete.

[JensNordenbro]

I am trying to build an exe targeting linux-arm according to: https://github.com/dotnet/corefx/blob/master/Documentation/project-docs/dogfooding.md

My csproj:

<Project Sdk="Microsoft.NET.Sdk">
  <PropertyGroup>
    <OutputType>Exe</OutputType>
    <TargetFramework>netcoreapp2.0</TargetFramework>
    <RuntimeIdentifiers>linux-arm</RuntimeIdentifiers>
    <RuntimeFrameworkVersion>2.0.0-preview1-25218-02</RuntimeFrameworkVersion> 
  </PropertyGroup>
  <ItemGroup>
      <PackageReference Include="runtime.linux-arm.Microsoft.Private.CoreFx.NETCoreApp" Version="4.4.0-preview1-25218-02" />
  </ItemGroup>
</Project>

The nuget.config points to a directory containg the corfx- and coreclr-nuget from the links above (versions in sync). When building using .net core 2.0.0 sdk, the output is:

error : Unable to resolve 'Microsoft.NETCore.App (>= 2.0.0-preview1-25218-02)' for '.NETCoreApp,Version=v2.0'. [C:\temp\core2-arm\core2-arm.csproj]
C:\Program Files\dotnet\sdk\2.0.0-preview1-005807\NuGet.targets(97,5): error : Unable to resolve 'Microsoft.NETCore.App (>= 2.0.0-preview1-25218-02)' for '.NETCoreApp,Version=v2.0 (win10-x64)'. [C:\temp\core2-arm\core2-arm.csproj]

Am I doing something wrong or is it just not supported?

[eerhardt]

Am I doing something wrong or is it just not supported?

You are using the wrong version for the runtime. RuntimeFrameworkVersion refers to which Microsoft.NETCore.App package you are referencing.

See https://dotnet.myget.org/feed/dotnet-core/package/nuget/Microsoft.NETCore.App for the latest versions of this package. (2.0.0-preview1-002028-00 is the latest package right now.)

[JensNordenbro]

Thanks @eerhardt , now it publishes! I have no arm to test my build on at this point in time but will try tomorrow. How does https://dotnet.myget.org/feed/dotnet-core/package/nuget/runtime.linux-arm.Microsoft.NETCore.Runtime.CoreCLR fit into all of this? It never is mentioned in the csproj.

[eerhardt]

From a "normal" user standpoint, none of this shows up in the .csproj. The way you pick your runtime is using the TargetFramework(s) property, and which packages are referenced underneath are an implementation detail: netcoreapp1.1 => Microsoft.NETCore.App v1.1x (where x is the latest patch). netcoreapp2.0 => Microsoft.NETCore.App v2.0.x. etc.

The Microsoft.NETCore.App package takes the output of CoreFX and CoreCLR and packages them up in one simple package for projects to reference. So when Microsoft.NETCore.App is built, it takes a version of https://dotnet.myget.org/feed/dotnet-core/package/nuget/runtime.linux-arm.Microsoft.NETCore.Runtime.CoreCLR, pulls all the "bits" out of it and re-packages it into itself.

[JensNordenbro]

Ok, so I have tried to run this using Yocto, Poky. The first output was libuv.so.9 is missing; if I add this dependency along with others by piggy backing on the Yocto-recipes in https://github.com/Tragetaschen/meta-aspnet/tree/master/recipes-dotnet it works. This recipe includes Kestrel along with OpenSSL etc. However I notice that when doing a publish I notice that the folder publish/runtimes/linux-arm/native contains libuv.so. Shouldn't that lib be picked up by dotnet when running? Is there some documentation stating the complete list of dependencies assumed on the target?

[eerhardt]

libuv was built into the "shared framework" in .NET Core 1.0 and 1.1. This was put there only for asp.net.

In .NET Core 2.0, we've removed libuv from "shared framework", and instead asp.net brings that dependency in itself. So you will need to update your asp.net references to use a recent asp.net 2.0.0-preview1 build.

Is there some documentation stating the complete list of dependencies assumed on the target?

I'm not aware of a document stating them all, but if you look in the dotnet/shared/Microsoft.NETCore.App/<version> folder, you will see which ones are included.