On Thu, Aug 28, 2014 at 3:27 AM, Richard Purdie <
richard.pur...@linuxfoundation.org> wrote:
> These patches illustrate a new idea, a way of allowing a single set of
> cross/native sstate to work over multiple 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 the patch is 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 cleanup 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 did want to send this out and 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.
>
> Signed-off-by: Richard Purdie <richard.pur...@linuxfoundation.org>
>
Hey Richard,
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.
--
Christopher Larson
clarson at kergoth dot com
Founder - BitBake, OpenEmbedded, OpenZaurus
Maintainer - Tslib
Senior Software Engineer, Mentor Graphics
--
_______________________________________________
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
