The sourcery toolchain writes temporary files to /tmp, and includes the
username. If multiple users are doing builds with pseudo enabled, it'll try to
write to the other user's file, since both will use 'root', and the build will
fail as a result.
Initially, I attempted to alter CC, KERNEL_CC, LD, etc to prepend with 'env
PSEUDO_UNLOAD=1 ', but this isn't ideal, as it seems there are cases where our
vars aren't obeyed. For example, the kernel build runs gcc -E, but it seems it
gets that from the cross-compiler prefix, not from CC, and we aren't passing
anything in for CPP. So, for now, use wrappers to deal with it, to ensure that
absolutely any call to any of the toolchain binaries will unload pseudo.
JIRA: MEIP-393, SB-1905
Signed-off-by: Christopher Larson <kergoth@gmail.com>
Using CSL_VER_MAIN = "2014.05-2014032705" or later allows us to remove
several patches that worked around ARM specific toolchain issues that
are now resolved in newer versions of sourcery-codebench toolchains.
This is needed currently, as our 2013.11 and 2014.05 IB 1 toolchains are
affected by gcc bug 58595, which is JIRA: CB-3083.
Signed-off-by: Christopher Larson <kergoth@gmail.com>
To make base address state tracing to work better or appliations that
fork without exec (e.g. daemons, web servers, ...) the following patch
is applied to lttng-ust:
lttng-ust/0001-Fix-Make-deadlocks-with-baddr-statedump-unlikely.patch
To work around an ARM specific compiler bug that causes babeltrace to
miscompile with optimizations the following patch is used:
babeltrace/do-not-optimize-parser.patch
To workaround a crosscompiling issue with babeltrace 1.2 the following
patch is used:
babeltrace/lttng-live-missing-header.patch
To enable building of lttng-modules for ARM the following modifications
are required to the recipe in poky:
packagegroup-core-tools-profile.bbappend
lttng-modules_2.4.0.bbappend
To enable compiling liburcu without --disable-compiler-tls on ARM the
following recipe is added:
liburcu_0.8.4.bb
When using an external linux-libc-headers recipe, we also don't want to ship
these headers, otherwise we get excessive warnings due to recipe sysroot file
overlap.
JIRA: SB-1501
Signed-off-by: Christopher Larson <kergoth@gmail.com>
Quiets a 'Files/directories were installed but not shipped' warning with some
toolchains.
JIRA: SB-1471
Signed-off-by: Christopher Larson <kergoth@gmail.com>
Quiets a 'Files/directories were installed but not shipped' warning when the
toolchain includes oprofile, but we're configured to prefer the real oprofile.
JIRA: SB-1471
Signed-off-by: Christopher Larson <kergoth@gmail.com>
Push out our append to TUNE_CCARGS to the end of the parse with _append, so it
shouldn't be affected by the e500v2 :=, and manually apply its gcc ice fix.
Signed-off-by: Christopher Larson <chris_larson@mentor.com>
It seems there are versions of the toolchain which provide empty directories,
which is a problem for anyone storing their toolchain in source control. So
ensure we only ever copy the paths that exist. Previously, we had left it as
is to make sure it *would* break if a path we require is missing, but
admittedly not all of these paths are critical, and if something is that badly
broken in the toolchain, other things are likely to break elsewhere anyway.
Signed-off-by: Christopher Larson <kergoth@gmail.com>
This information should be informative, covering exactly what the layer.conf and tcmode file are doing. In addition, it should address concerns about configuration migration from old versions of oe-core, without explicitly instructing the user in steps they may not need to perform.
This also adds instructions on the use of `external-sourcery-rebuild-libc`.
Don't do so in our default configuration, however. This quiets the warnings
encountered when using 2013.05 sourcery toolchains.
Signed-off-by: Christopher Larson <chris_larson@mentor.com>
This means we won't be able to build meta-toolchain with an external
toolchain, but it does mean we don't screw up buildtools-tarball. If we need
a functional meta-toolchain in the future, we can resurrect a superior
implementation of this.
Signed-off-by: Christopher Larson <chris_larson@mentor.com>
