* 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>
There's a bug where the implicitly created
`PREFERRED_PROVIDER_${MLPREFIX}<provider>` isn't being obeyed for
runtime package installation in a multilib image, so work around it by
explicitly specifying mlprefix.
Signed-off-by: Christopher Larson <chris_larson@mentor.com>
This is used in recipe PV variables, but is only defined when the tcmode
is loaded, so define a default for the case where it isn't sourced.
Signed-off-by: Christopher Larson <chris_larson@mentor.com>
This returns immediately with 'UNKNOWN' if the external toolchain isn't
enabled, and also immediately adjusts sys.path regardless of OE_IMPORTS
handling to avoid the over-reliance upon that mechanism.
Signed-off-by: Christopher Larson <chris_larson@mentor.com>
The blacklist isn't necessary. We already provide the virtual, but if
someone wants the real thing, it shouldn't be harmful to allow it to
build.
Signed-off-by: Christopher Larson <chris_larson@mentor.com>
We don't want to encourage use of alternate versions of this recipe, there are
better ways to add additional headers.
Signed-off-by: Christopher Larson <chris_larson@mentor.com>
This makes it clear that this refers to the toolchain, not the CodeBench IDE.
JIRA: SB-8699
Signed-off-by: Christopher Larson <chris_larson@mentor.com>
We only want this to take effect for the locales for the external toolchain,
not those generated and used for nativesdk, otherwise we break the
buildtools-tarball build.
JIRA: SB-8391
Signed-off-by: Christopher Larson <chris_larson@mentor.com>
Since the external-cross recipes link/wrap the binaries already, there's no
actual need to override TARGET_PREFIX anymore.
Signed-off-by: Christopher Larson <chris_larson@mentor.com>
Using the one already available with our toolchain makes a great deal of
sense, as it's a known quantity. The only reason we switched to gdb was due to
conflicts between gdb and gdbserver-external, but that issue has been
resolved.
Signed-off-by: Christopher Larson <chris_larson@mentor.com>
It's not ideal to do this for every build, but it's not terrible, either, and
is worth the cost to get an error up front if there's a configuration or
licensing problem. master deals with this more cleanly.
JIRA: SB-8257
Signed-off-by: Christopher Larson <chris_larson@mentor.com>
- Reworked to function the way sanity.bbclass does, rather than running it
every time we do a build
- Add sanity check to test trivial compilation
Signed-off-by: Christopher Larson <chris_larson@mentor.com>
We were hitting issues due to non-deterministic ordering of ConfigParsed event
handlers between codebench.bbclass and the tcmode. To avoid this, consolidate
the two and use a single handler.
Signed-off-by: Christopher Larson <chris_larson@mentor.com>
It's useful to know which target triplet/system was selected by the logic in
the tcmode file, as it searches EXTERNAL_TOOLCHAIN to determine which to use.
Signed-off-by: Christopher Larson <chris_larson@mentor.com>
If the user hasn't set EXTERNAL_TOOLCHAIN, but CODEBENCH_PATH is set, then we
automatically set both EXTERNAL_TOOLCHAIN and EXTERNAL_TARGET_SYS based on the
installed toolchains in CODEBENCH_PATH/../toolchains.
This adds a new variable, rather than allowing EXTERNAL_TOOLCHAIN to point to
CodeBench instead of the actual toolchain path, to keep the clean separation
between the generic toolchain logic and that which is specific to our
toolchains, and also avoids overloading the variable's meaning.
JIRA: SB-7881
Signed-off-by: Christopher Larson <chris_larson@mentor.com>
