| Age | Commit message (Collapse) | Author |
|---|
|
If glibc is newer on the host than in uninative, the failure mode is
pretty nasty for clusters where the sstate is shared, including the Yocto
Project autobuilder.
This check aborts the use of uninative in such scenarios where a newer
glibc version appears and avoids corruption of sstate caches.
We use ldd to check the glibc version since that is included in libc-bin
(or equivalent) which locales use so it should always be present.
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
We've been seeing hangs in smart on the autobuilders where it hangs in
pthread futex calls. It appears to happen when some components are
installed from sstate (which use the interpreter from uninative)
and other components are built natively (and use the host's interpreter).
Its primarily affecting software which uses shared memory with futexs in
for locking purposes (which bdb does called from librpm from smart).
This isn't an issue in pyro and rocko and beyond since they use recipe
specific sysroots which included a change to always change to the
uninative interpreter. We could backport those changes but they're
fairly invasive changes to the sstate code. This patch is a more
minimal change which ensures binaries are always using the uninative
interpreter regardless of whether they're built locally or installed
from sstate.
This is only an issue if you're using an sstate mirror and hosts
with a variety of different libc versions. It has only become an issue
on recent libc versions where there was clearly some forwards compatibility
issue introduced.
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
This means that a user can change TMPDIR in a multiconfig situation
and still only have one path to the uninative setup. Without this change
its not possile to make such a setup work.
(From OE-Core rev: 779422c5458f5f643b3a4a0dedaa4d9ad709367a)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
Some c++ libraries fail to build if uninative is built
with gcc 5.x and host gcc version is either 4.8 or 4.9.
The issue should be solved by making separate uninative sstate
directory structure sstate-cache/universal-<gcc version> for host gcc
versions 4.8 and 4.9. This causes rebuilds of uninative if host gcc
is either 4.8 or 4.9 and it doesn't match gcc version used to build
uninative.
[YOCTO #10441]
(From OE-Core rev: d36f41e5658bbbb6080ee833027879c119edf3e0)
Signed-off-by: Ed Bartosh <ed.bartosh@linux.intel.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Signed-off-by: Armin Kuster <akuster808@gmail.com>
|
|
Create a common include file for compiler flags which allow native binaries to
be interoperable on a wide range of hosts. In particular the C++ ABI is
problematic so choose the CXX11 version to allow interoperation between gcc4 and
gcc5 based hosts. Moving this to a common include instead of uninative.bbclass
allows uninative to be configured later and used in the eSDK (where its
mandatory) even if the base configuration doesn't enable uninative by default
(e.g. nodistro in OE-Core).
[ YOCTO #10645 ]
(From OE-Core rev: 60c912ae9306532bdd4c5e09a65863ee77c12f43)
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Signed-off-by: Armin Kuster <akuster808@gmail.com>
|
|
There are various concerns about md5 so use sha256 instead.
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
patchelf will understandably error out if there isn't a .interp section to
relocate, so don't try to relocate static binaries.
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
If no -std= option is passed to icu's configure, it defaults to CXX11.
This isn't what we want for uninative, so pass an explicit option
which selects an older ABI on newer versions of g++.
This avoids the __cxa_bad_array_new_length@CXXABI_1.3.8 symbol
being used.
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
uninative hand codes the list of files which need relocation, add the libc
to that list to ensure GCONF_PATH is updated.
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
We need to be able to update uninative if the version changes. To do this,
stash a checksum of the installed uninative tarball into a file. If this
changes, we update uninative.
For cleaner download messages, we place the tarballs into directories
based on the checksum.
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
Move duplicate code into a common function
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
We may see binaries built with gcc5 run or linked into gcc4 environment
so use the older libstdc++ standard for now until we don't support gcc4
on the host system. https://wiki.debian.org/GCC5 has more details about this.
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
The previous attempt at soft-failing when uninative was enabled didn't actually
work, because the workers didn't evaluate the function that actually enabled
uninative.
In a BuildStarted handler we can check if we need to download or extract the
uninative tarball.
In a ConfigParsed handler on the workers we can check if the uninative loader is
present, and if so enable it.
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
Signed-off-by: Ross Burton <ross.burton@intel.com>
|
|
Signed-off-by: Ross Burton <ross.burton@intel.com>
|
|
Signed-off-by: Ross Burton <ross.burton@intel.com>
|
|
Instead of raising a generic Exception that can't be handled specifically, raise
a ValueError. Also update the callers so any unexpected exceptions are not
ignored.
Also, rename isBigEngian() to isBigEndian().
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
When patchelf-uninative fails, reporting only the exit code
as done by subprocess.check_call() is not enough to understand
the problem. We also need to capture and report the output
of the command.
Signed-off-by: Patrick Ohly <patrick.ohly@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
We need to improve the error handling here, things were breaking and
yet the user wasn't seeing the issues. We need to skip libraries as
we process the files.
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Signed-off-by: Ross Burton <ross.burton@intel.com>
|
|
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.
Signed-off-by: Ross Burton <ross.burton@intel.com>
|
|
When uninative was changed to use it's own sysroot the path to patchelf lost
${bindir_native}, so add it back.
Signed-off-by: Ross Burton <ross.burton@intel.com>
|
|
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.
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.
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]
Signed-off-by: Randy Witt <randy.e.witt@linux.intel.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
|
|
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.
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
Richard Purdie
Ed Bartosh
Ross Burton
Patrick Ohly
Randy Witt