These patches are the start of a new idea, a way of allowing a single set of
cross/native sstate to work over mutliple distros, even old ones.
The assumption is that our own C library is basically up to date. We build
and share a small tarball (~2MB) of a prebuilt copy of this along with a
patchelf binary (which sadly is C++ based so libstdc++ is in there). This
tarball can be generated from our usual SDK generation process through
the supplied recipe, uninative-tarball.
At the start of the build, if its not been extracted into the sysroot, this
tarball is extracted there and configured for the specified path.
When we install binaries from a "uninative" sstate feed, we change the
dynamic loader to point at this dynamic loader and C librbary. This works
exactly the same way as our relocatable SDK does. The only real difference
is a switch to use patchelf, so even if the interpreter section is too small,
it can still adjust the binary.
Right now this implements a working proof of concept. If you build the tarball
and place it at the head of the tree (in COREBASE), you can run a build from
sstate and successfully build packages and construct images.
There is some improvement needed, its hardcoded for x86_64 right now, its trivial
to add 32 bit support too. The tarball isn't fetched right now, there is just a
harcoded path assumption and there is no error handling. I haven't figured
out the best delivery mechanism for that yet. BuildStarted is probably not
the right event to hook on either.
I've merged this to illustrate how with a small change, we might make the
native/cross sstate much more reusable and hence improve the accessibility
of lower overhead builds. With this change, its possible the Yocto Project may
be able to support a configured sstate mirror out the box. This also has
positive implications for our developer workflow/SDK improvements.
(From OE-Core rev: e66c96ae9c7ba21ebd04a4807390f0031238a85a)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2cbab459e4