If the local fetcher is used then files are not actually fetched into DL_DIR, so
check if this happened and if required add a symlink to the real file.
(From OE-Core rev: a13b0a0b79cf4db9f247facf71c03344b60be890)
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
When uninative was changed to use it's own sysroot the path to patchelf lost
${bindir_native}, so add it back.
(From OE-Core rev: d986f90937b7b4c60128003ef5d30d01ac1653e3)
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Currently this code installs into the standard sysroot, however this causes
some conflicts when linking since the linker can look specifically for
versioned .so files (e.g. like libpthreads.so.0). This breaks builds
of util-linux-native for example.
The easiest solution is to install uninative into its own separate sysroot.
(From OE-Core rev: e2403bc637e2967a028718058f987cc8841a6edc)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Originally, the idea was that the init environment would handle
fetching or providing the binary shim that uninative needs.
This turns out to be ugly, especially when you consider proxy
environments and so on getting involved. Instead, lets therefore
support our fetcher which already handles all this.
The distro is expected to setup configuration like:
UNINATIVE_URL ?= "http://mydomain/mypath/"
UNINATIVE_CHECKSUM[i586] =
"md5sum1"
UNINATIVE_CHECKSUM[x86_64] = "md5sum2"
and then it should all work if the user inherits the uninative class.
This patch also improves the error handling in the class to give more
user readable error messages.
If the shim binary is already provided, the system will just use that
and ignore the url information.
(From OE-Core rev: 89097d2d7bf058136b01ec982b9453b49052b1d8)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Previously UNINATIVE_LOADER was always ld-linux-x86-64.so.2. That is
incorrect when the host is 32-bit.
This change also changes to using ?= so the user can override
UNINATIVE_LOADER if so desired.
[YOCTO #8124]
(From OE-Core rev: b78fa0bcadd54bb29b6f1bb3a9308d4c454bf4e2)
Signed-off-by: Randy Witt <randy.e.witt@linux.intel.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
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>
Ross Burton
Richard Purdie
Randy Witt