[Discussion] Better support for OpenEmbedded / Yocto

[Tragetaschen]

Yocto is a meta-distribution that you customize for your own (usually embedded) platform using layers containing recipes for libraries and tools. It's build-tool is called bitbake. Im running on the "sumo" release.

During the last two days, I've updated my OpenEmbedded layer to use this source-build repository when building the .NET Core 2.1 runtime. Currently these efforts are limited to Linux/ARM, because the cross-compilation infrastructure assumes quite a lot that isn't true in the bitbake environment, and bending the source-build build tools is quite architecture specific.

Within the bitbake build environment, I have a fully and correctly set up cross-compilation environment with

• RootFS per recipe with all the declared build dependencies
• Cross-compiler is available using the usual environment variables (CC, CFLAGS, CXXFLAGS, LD…)
• Full cmake support with all folder references and whatnot already set up

The ad-hoc patches to source-build and the submodules scatter parts of that into the necessary places so the result is a working executable on the target platform.

In particular:

• The ${TOOLCHAIN} is not arm-linux-gnueabihf, but depends on the distribution. For me, it's arm-target-linux-gnueabi where "target" is the name of my distribution, so this needs to be put into all the various toolchain.cmake files that set it unconditionally.
• The -target is the same as the toolchain and not armv7-gnueabihf. Instead, bitbake configures the compiler invocation using -march=armv7l -mfloat-abi=hard to set the actual processor type (example here.
• I've forced linux-arm as RID into the build scripts. The actual distribution name is likely nothing .NET Core understands (target-f000 in my case).
• I've added the ability to disable the RootFs generation that is otherwise always on and instead point to the generated one
• Due to differences in the layout of the RootFS, some explicit include path manipulation breaks the build: https://github.com/dotnet/corefx/issues/16531
• Core-setup very-hard-codes the clang version while the Bitbake environment only has the non-versioned executables.

Interestingly, I was able to successfully use a lot more recent tools and libraries. For instance, clang 6.0.1 or Glibc 2.27 nearly out of the box (https://github.com/dotnet/coreclr/18983)

I had looked into skipping the build scripts and instead distill what they do into my recipe, but found the amount of setup before the actual calls to cmake too infeasible. Also, this wouldn't scale to any future build changes.

In the end, I would love to see broader support for cross-compilation beyond the explicit and hard-coded platforms currently available through the build script.

Thoughts?

[dleeapho]

/cc @leecow @richlander

[deinok]

@Tragetaschen I'm very interested in this but in a i586x embedded device. (For now i'm using mono)
I'm working on setting up dotnet in x86 but the final target will be a yocto based device.

[lukedukeus]

I am running into a situation where I need dotnet installed in my Yocto image, but I am unable to use MS's prebuilt dotnet binaries because my CPU supports vfpv3-d16, whereas the prebuilt binaries support vfpv3. I found this issue today, and I'm posting here to see if anyone has made any progress using recent dotnet (v5+) in a yocto image?

I have attempted to write my own dotnet-native recipe that would allow for using dotnet in the Yocto build process, but it is proving to be a lot of work because I need to write native recipes for all of dotnet's dependencies. Another issue is dotnet requires dotnet as part of the build process, or it tries to download it, which yocto doesn't allow in its build process.