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>
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>
Long term, may want to add the ability to ship the cross-canadian content from
the external toolchain.
Signed-off-by: Christopher Larson <chris_larson@mentor.com>
To avoid issues when a user installed a Sourcery toolchain to the default path
and let it modify their PATH, we iterate over PATH and remove the problematic
elements. Unfortunately, in doing so, we inadvertently forced an early
expansion of PATH due to getting it in its expanded form, then setting PATH
based on that form. Instead, operate against the unexpanded PATH.
Signed-off-by: Christopher Larson <chris_larson@mentor.com>
The toolchain installer can end up modifying the user's PATH via their
dotfiles, but if the ia32 sourcery g++ toolchain is always in the user's path,
things can fail to build, as the ia32 toolchain provides non-prefixed binaries
(e.g. 'gcc', 'ld').
Signed-off-by: Christopher Larson <chris_larson@mentor.com>
BitBake doesn't run event handlers in registration order, which means there's
no way to know if a given bit of code (e.g. the tcmode set of
EXTERNAL_TOOLCHAIN_SYSROOT) has been set, from a different event handler. So
go back to using ${@}.
Signed-off-by: Christopher Larson <chris_larson@mentor.com>
Lite toolchains don't include support for native libraries and thus
-msgxx-glibc is not a valid option. Added a check to see if the tools contain
a license directory to determine whether a pro (true) or lite (false)
toolchain is being used and set TUNE_CCARGS_append_x86 accordingly.
Tested with both Lite and pro toolchains.
Signed-off-by: Michael Powell <michael_powell@mentor.com>
