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>
Internal toolchains generally don't see these, as they build that toolchain
with the default behavior they expect, so it's appropriate to include these
fixes with the external toolchain configuration, for now.
Signed-off-by: Christopher Larson <chris_larson@mentor.com>
Now that KERNEL_LD uses ld.bfd, we need to ensure that it exists when using an
external toolchain.
Signed-off-by: Christopher Larson <chris_larson@mentor.com>
* mel/master:
external-sourcery-toolchain: kill more bits we don't want in eglibc-utils
Work around upstream FILESDIR/FILESPATH changes
external-sourcery-toolchain: fix dev vs staticdev packaging issue
external-sourcery-toolchain: kill oprofile bits
external-sourcery-toolchain: silence GNU_HASH warning for libquadmath
tcmode: prefer a matching gcc version for target recipes
external-sourcery-toolchain: add libquadmath packages
external-sourcery-toolchain: kill ${exec_prefix}/lib/locale in do_install_locale
external-sourcery-toolchain: also package ${prefix}/libexec
external-sourcery-toolchain: forgot to rstrip the trailing newline
Conflicts:
recipes/meta/external-sourcery-toolchain.bb
Signed-off-by: Christopher Larson <chris_larson@mentor.com>
As do_install_locale already copied these into the sysroot to be picked up by
eglibc-locale, there's no reason to keep the files around for ourselves.
Note: this should go into the oe-core eglibc-package.inc.
Signed-off-by: Christopher Larson <chris_larson@mentor.com>
As do_install_locale already copied these into the sysroot to be picked up by
eglibc-locale, there's no reason to keep the files around for ourselves.
Note: this should go into the oe-core eglibc-package.inc.
Signed-off-by: Christopher Larson <chris_larson@mentor.com>
This is needed, as even if libexecdir isn't ${prefix}/libexec, our already
built eglibc will be expecting its files there. Without this, we get package
QA failures with current oe-core, which changed libexecdir to ${libdir}/${PN}.
Signed-off-by: Christopher Larson <chris_larson@mentor.com>
