<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Aug 28, 2014 at 3:27 AM, Richard Purdie <span dir="ltr"><<a href="mailto:richard.purdie@linuxfoundation.org" target="_blank">richard.purdie@linuxfoundation.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div id=":hz" class="a3s" style="overflow:hidden">These patches illustrate a new idea, a way of allowing a single set of<br>
cross/native sstate to work over multiple distros, even old ones.<br>
<br>
The assumption is that our own C library is basically up to date. We build<br>
and share a small tarball (~2MB) of a prebuilt copy of this along with a<br>
patchelf binary (which sadly is C++ based so libstdc++ is in there). This<br>
tarball can be generated from our usual SDK generation process through<br>
the supplied recipe, uninative-tarball.<br>
<br>
At the start of the build, if its not been extracted into the sysroot, this<br>
tarball is extracted there and configured for the specified path.<br>
<br>
When we install binaries from a "uninative" sstate feed, we change the<br>
dynamic loader to point at this dynamic loader and C librbary. This works<br>
exactly the same way as our relocatable SDK does. The only real difference<br>
is a switch to use patchelf, so even if the interpreter section is too small,<br>
it can still adjust the binary.<br>
<br>
Right now the patch is a working proof of concept. If you build the tarball<br>
and place it at the head of the tree (in COREBASE), you can run a build from<br>
sstate and successfully build packages and construct images.<br>
<br>
There is some cleanup needed, its hardcoded for x86_64 right now, its trivial<br>
to add 32 bit support too. The tarball isn't fetched right now, there is just a<br>
harcoded path assumption and there is no error handling. I haven't figured<br>
out the best delivery mechanism for that yet. BuildStarted is probably not<br>
the right event to hook on either.<br>
<br>
I did want to send this out and illustrate how with a small change, we might<br>
make the native/cross sstate much more reusable and hence improve the accessibility<br>
of lower overhead builds. With this change, its possible the Yocto Project may<br>
be able to support a configured sstate mirror out the box. This also has<br>
positive implications for our developer workflow/SDK improvements.<br>
<br>
Signed-off-by: Richard Purdie <<a href="mailto:richard.purdie@linuxfoundation.org">richard.purdie@linuxfoundation.org</a>></div></blockquote></div><br>Hey Richard,</div><div class="gmail_extra"><br></div><div class="gmail_extra">This looks extremely promising. I tried using it, however, and ran into all manner of problems. The first one is relatively easy to resolve, and I have a local patch which seems to do so (though I then run into different build failures): binaries which are built and then run, before any relocation patchelf bits are run (e.g. autoconf ./conftest), can fail miserably due to the mismatch between the libc they linked against in the sysroot and the host dynamic linker, unless you add -Wl,--dynamic-linker=${UNINATIVE_LOADER} or so to BUILD_LDFLAGS.<br>-- <br>Christopher Larson<br>clarson at kergoth dot com<br>Founder - BitBake, OpenEmbedded, OpenZaurus<br>Maintainer - Tslib<br>Senior Software Engineer, Mentor Graphics
</div></div>