[Discussion] Better support for OpenEmbedded / Yocto #655
Labels
area-build
Improvements in source-build's own build process
area-native-bootstrapping
Allowing new platforms/operating systems to use source-build
Uh oh!
There was an error while loading. Please reload this page.
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
CC
,CFLAGS
,CXXFLAGS
,LD
…)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:
arm-linux-gnueabihf
, but depends on the distribution. For me, it'sarm-target-linux-gnueabi
where "target" is the name of my distribution, so this needs to be put into all the varioustoolchain.cmake
files that set it unconditionally.-target
is the same as the toolchain and notarmv7-gnueabihf
. Instead, bitbake configures the compiler invocation using-march=armv7l -mfloat-abi=hard
to set the actual processor type (example here.linux-arm
as RID into the build scripts. The actual distribution name is likely nothing .NET Core understands (target-f000
in my case).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?
The text was updated successfully, but these errors were encountered: