uninative: Add uninative - a way of reusing native/cross over multiple distros
RFC PATCH 1/1 uninative: Add uninative - a way of reusing native/cross over multiple distros
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.
meta/classes/uninative.bbclass new file +47 -0
@@ -0,0 +1,47 @@ +#BUILD_LDFLAGS += "-Wl,-T${LINKERSCRIPT}" +NATIVELSBSTRING = "universal" +#LINKERSCRIPT = "${STAGING_DIR_NATIVE}/linkerscript" + +addhandler uninative_eventhandler +uninative_eventhandler[eventmask] = "bb.event.BuildStarted" + +python uninative_eventhandler() { + loader = e.data.getVar("UNINATIVE_LOADER", True) + if not os.path.exists(loader): + import subprocess + cmd = e.data.expand("mkdir -p ${STAGING_DIR}; cd ${STAGING_DIR}; tar -xjf ${COREBASE}/${BUILD_ARCH}-nativesdk-libc.tar.bz2; ${STAGING_DIR}/relocate_sdk.py ${STAGING_DIR_NATIVE} ${UNINATIVE_LOADER} ${UNINATIVE_LOADER} ${STAGING_BINDIR_NATIVE}/patchelf-uninative") + #bb.warn("nativesdk lib extraction: " + cmd) + subprocess.check_call(cmd, shell=True) +} + +SSTATEPOSTUNPACKFUNCS_append = " uninative_changeinterp" + +UNINATIVE_LOADER = "${STAGING_DIR_NATIVE}/lib/ld-linux-x86-64.so.2" + +python uninative_changeinterp () { + import subprocess + import stat + import oe.qa + + if not (bb.data.inherits_class('native', d) or bb.data.inherits_class('crosssdk', d) or bb.data.inherits_class('cross', d)): + return + + sstateinst = d.getVar('SSTATE_INSTDIR', True) + for walkroot, dirs, files in os.walk(sstateinst): + for file in files: + f = os.path.join(walkroot, file) + if os.path.islink(f): + continue + s = os.stat(f) + if not ((s[stat.ST_MODE] & stat.S_IXUSR) or (s[stat.ST_MODE] & stat.S_IXGRP) or (s[stat.ST_MODE] & stat.S_IXOTH)): + continue + elf = oe.qa.ELFFile(f) + try: + elf.open() + except: + continue + + #bb.warn("patchelf-uninative --set-interpreter %s %s" % (d.getVar("UNINATIVE_LOADER", True), f)) + subprocess.call("patchelf-uninative --set-interpreter %s %s" % (d.getVar("UNINATIVE_LOADER", True), f), shell=True) +} +
meta/recipes-core/meta/uninative-tarball.bb new file +48 -0
48 lines not on this page · raw message
Quoted 8 lines · Richard Purdie
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).
Begs for patchelf built against uClibc++ for the build.
Otherwise I like the idea!
Thanks,
Quoted 41 lines · Richard Purdie
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_64right 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.
Quoted 2 lines
Signed-off-by Richard Purdie <[email protected]>
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.
Signature · 5 lines
Christopher Larson clarson at kergoth dot com Founder - BitBake, OpenEmbedded, OpenZaurus Maintainer - Tslib Senior Software Engineer, Mentor Graphics