Enable .NET Core on Yocto Linux

[Tragetaschen]

In https://github.com/Tragetaschen/meta-aspnet/tree/master/recipes-dotnet/corehost, there are some bitbake recipes that compile CoreCLR, CoreFX and core-setup for inclusion a in Yocto Linux based distribution for ARM.

The git commits used follow the versions in pkg/projects/Microsoft.NETCore.App/project.json.template, to get to a consistent set of packages for core-setup to pick up from a local NuGet folder.

As a RID, this setup currently (mis)uses ubuntu.16.04-arm, but of course it's not Ubuntu. I haven't yet found a good way to get to a better RID since Yocto/OpenEmbedded is a meta-distribution used to create actual, embedded distributions depending on ones needs. I'll try to summarize my thoughts below.

The recipes currently contain a handful of patches that tame the build environment to actually compile. I'll create some issues in the appropriate repos.

And before I forget:
Many thanks to @ernstp for doing all the hard work enabling the 2.0 Yocto builds!
And of course to all the people that ported .NET Core to ARM in the first place!

[Tragetaschen]

Regarding a RID for Yocto/Linux, I'm currently trying to bring together the meta-distribution nature on the one hand and the wish to target the resulting distribution with my own nupkgs.

Yocto itself has the concept of releases (the current one is called morty or 2.2), but this only denotes a couple of "recipes" for libraries and programs that can be included in an actual distribution. For example, Yocto itself comes with a default distribution called poky (again version 2.2), and also a poky-tiny, a poky-lsb and a poky-bleeding one.

Beyond that, you are free to define your own distributions (mine is called target with version 1.0). Each distribution can be augmented by additional "layers" (e.g. "meta-aspnet", or "meta-mono") that can quite freely add additional, reconfigure existing, or override versions for packages. For example, "meta-aspnet" requires "meta-clang" so that compiler becomes available. Once you start customizing images beyond what was released as "Yocto 2.2", you are responsible for the integration testing on your actual system.

In the end, a yocto.2.2-arm RID (plus yocto.2.2, yocto, yocto-arm towards linux-arm) doesn't mean anything specific—a package author doesn't know what to expect—but its something known beyond a specialized Yocto distribution. On the other hand the "correct" RIDs like poky.2.2-arm or target.1.0-arm won't have a place for example here in the core-setup context, but are something that I would like to target in a package (non-published of course)

[JensNordenbro]

My vote for this too. All the other efforts for .net core on arm centers around the iot or consumer level of linux. This efforts is about embedded linux, where you create your own minimal distribution.

[JensNordenbro]

@Tragetaschen, would it be possible to do it differently? Define a meta-dotnet-core-dependencies that is binary compatible towards tizen/ubuntu/whateverdist most aligned to poky, "supported" by Microsoft, hence aligning to a rid and therefor being able to run daily builds from coresetup and consume nugets with native parts targeting all common rids?

[darrensteadman]

Has this progressed any further? I'd be very interested in being able to get .NET Core running on Yocto.

[frankhommers]

+1 same for me too. Would be great to write embedded in C#

[jamespettigrew]

Would like to see this too.

[pauldotknopf]

Can we get some input from the Microsoft team? I feel like we should have them weigh in on how the RID should work.

[Petermarcu]

My first reaction is that while rids may be able to be used for this, the complexity of trying to describe and represent all kinds of intersections will be close to a nightmare.

It is possible for someone to define an arbitrary RID graph. So based on a Yocto recipe that gets a name (like target from above) you could have a package you reference that brings in the RID definition for target which then would be used by NuGet to pick assets from the packages.

In summary, I dont think we should try to represent all the arbitrary subsets in the official RID graph but on a case by case basis, RIDs could be used within a scoped context.

@ericstj , can you do a small writeup on how people can add to the RID graph in their own package?

[Petermarcu]

I am hoping that the linux-arm RID works for Yocto assuming the recipe used pulls in at least the dependencies required by .NET Core. I need to put together a good list of dependencies that are required somewhere.

[Petermarcu]

Looks like in https://github.com/Tragetaschen/meta-aspnet/tree/master/recipes-dotnet/corehost we'll need to get core-setup building as well. Thats where the dotnet host builds and is the thing that knows how to act like .NET Core. Corehost is over simplified.

[JensNordenbro]

We run linux arm rid on yocto. We use tragetaschen to bring in dependencies and then use binaries linked from core setup Readme.md or just publish the source to self contained deployment using rid linux-arm. This way, as long as my yocto is glibc compatible, even third party nugets with native dependencies will work. The dotnet host in tragetaschen will also work but the last time I ran it, it assumed ubuntu-arm rid.

[Petermarcu]

Great, yes, thats what I hoped. So as long as you have the dependencies built into your yocto recipe, the binaries provided in our packages for linux-arm just work.

[pauldotknopf]

Out of curiosity, what would happen if I bring in Libuv as a dependency package? It doesn't have the linux-arm binaries. Does that mean a recipe will have to be built that will compile the libuv .so files?

[Petermarcu]

The latest preview package does have linux-arm. https://www.nuget.org/packages/Libuv/1.10.0-preview1-22040

[JensNordenbro]

It would be nice @Petermarcu if Microsoft at least provided a list for coreclr, corefx native dependencies or even better this list translated to a yocto definition...
Or maybe a cli extension to validate coreclr, corefx prerequisites. Like

dotnet validate-system