Skip to content

[Discussion] Better support for OpenEmbedded / Yocto #655

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

Open
Tragetaschen opened this issue Jul 18, 2018 · 3 comments
Open

[Discussion] Better support for OpenEmbedded / Yocto #655

Tragetaschen opened this issue Jul 18, 2018 · 3 comments
Labels
area-build Improvements in source-build's own build process area-native-bootstrapping Allowing new platforms/operating systems to use source-build

Comments

@Tragetaschen
Copy link

Tragetaschen commented Jul 18, 2018

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
Copy link
Contributor

/cc @leecow @richlander

@deinok
Copy link

deinok commented Jul 31, 2018

@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
Copy link

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area-build Improvements in source-build's own build process area-native-bootstrapping Allowing new platforms/operating systems to use source-build
Projects
Status: Backlog
Development

No branches or pull requests

6 participants