* origin/sumo:
Silence gdbserver preference warnings in multilib builds
gdb: fix missing mlprefix for gdbserver pref
tcmode: work around mlprefix preference bug wrt gdbserver
gdbserver-external: add missing MLPREFIX in dep on compilerlibs
{glibc,gcc-runtime}: fix warnings about libssp for builds with security flags
meta-environment{,-extsdk}: don't include -B${gcc_bindir} in emitted TUNE_CC_ARCH
Signed-off-by: Christopher Larson <chris_larson@mentor.com>
DEPENDS/PROVIDES & PREFERRED_PROVIDER get mapped for mlprefix
automatically, but 'depends' flags do not, so the MLPREFIX has to be
explicit in such flags. This fixes the ability to build multilib images,
i.e. lib32-core-image-base.
Signed-off-by: Christopher Larson <chris_larson@mentor.com>
Also provide external-common.bbclass to wrap its inclusion and setup
associated metadata. This will make easier to search sysroots for files
without pulling in the rest of the external toolchain class.
Signed-off-by: Christopher Larson <chris_larson@mentor.com>
Since external recipes don't require virtual/libc and the compilerlibs, we
won't always get our rdeps on those from the shlibs processing, unless we
depend on the packagedata from those recipes. Adding them to DEPENDS would
have worked too, but would have been a lie in a sense, as we don't actually
require those to "build", just package.
Signed-off-by: Christopher Larson <kergoth@gmail.com>
common-license.bbclass will set LIC_FILES_CHKSUM to a common license file
based on LICENSE, which is appropriate for a case where we have no sources to
refer to.
external-toolchain.bbclass, among other things, handles extraction of files in
the external toolchain sysroot, based on patterns in the FILES variables,
checking alternate locations to better support any arbitrary toolchain, and
has basic mirror handling for checking multiple paths within the sysroots.
Under normal circumstances, I'd want this to use highly granular commits, but
this branch has been extremely long lived (>1yr) and is such an invasive
refactoring that attempting to break it down now would be of limited
usefulness.
Signed-off-by: Christopher Larson <chris_larson@mentor.com>
