* 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>
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>
This can be dropped if and when the toolchain gets built without libssp,
which is the default in oe-core. We don't need gcc's libssp anyway,
since glibc provides it already, and musl has the separate
libssp_nonshared lib to supplement, which is in oe-core.
JIRA: SB-12465
Signed-off-by: Christopher Larson <chris_larson@mentor.com>
Don't dump the -B${gcc_bindir} appended to TUNE_CCARGS and subsequently
to TARGET_CC_ARCH, since it consists of local machine toolchain paths.
Signed-off-by: Christopher Larson <chris_larson@mentor.com>
* origin/sumo:
external-common.bbclass: fix long standing oe.external import issue
bash: check if support/bash.pc exist before running sed
bash: drop -B${gcc_bindir} from bash.pc
external-toolchain.bbclass: add missing mlprefix in binutils dep
oe.external: handle invalid FILES_MIRRORS entries
glibc-external: add virtual/crypt to PROVIDES
Signed-off-by: Christopher Larson <chris_larson@mentor.com>
bitbake-layers and devtool both fail to run commands with
meta-external-toolchain included, as it fails to import oe.external. It
turns out that oe_import in base.bbclass is not entirely sufficient to
get the needed modules imported when namespace packages are involved,
and those packages have already been imported. Re-import such packages
after the sys.path change to ensure the new __init__.py files are
parsed, and the new __path__ changes picked up.
JIRA: SB-11904
Signed-off-by: Christopher Larson <chris_larson@mentor.com>
The bash version provided by meta-gplv2 does not provide this file and
as a consequence do_compile will fail with:
sed: can't read support/bash.pc: No such file or directory
Signed-off-by: Frederik Noe-Sdun <Frederik_NoeSdun@mentor.com>
Signed-off-by: Christopher Larson <chris_larson@mentor.com>
* external-cross-canadian: (21 commits)
tcmode-external: prefer gdb-external-cross
gdb-external-cross: add recipe
tcmode-external: default to external-cross-canadian recipes
tcmode-external: blacklist cross-canadian recipes
external-toolchain-cross-canadian: append to PN in the recipes
gcc-external-cross-canadian: also include libcc1*
gcc-external-cross-canadian: also check the external libroot
gcc-external-cross-canadian: only grab the BINV dir, not all of lib/gcc
gcc-external-cross-canadian: skip dev-so/staticdev qa tests
gcc-external-cross-canadian: add recipe
gdb-external-cross-canadian: use FILES_MIRRORS for alternate share/gdb path
gdb-external-cross-canadian: skip dev-so, staticdev checks
gdb-external-cross-canadian: split out and use gdb-external.inc
gdb-external-cross-canadian: add recipe
binutils-external-cross{,canadian}: include ld.bfd, ld.gold
binutils-external-cross-canadian: add recipe
binutils-external-cross: split out binutils-external.inc
external-toolchain-cross-canadian.bbclass: drop the binutils-cross dep
external-toolchain-cross-canadian.bbclass: use host strip/objcopy
external-toolchain-cross-canadian: ship TARGET_PREFIX symlinks
...
When EXTERNAL_TARGET_SYS != TARGET_PREFIX, which is generally the case,
we should ship symlinks with the other prefix. This is largely for
compatibility with existing scripts, but also means we don't need to
alter the variables in environment-setup, i.e. CC.
Signed-off-by: Christopher Larson <chris_larson@mentor.com>
This class will be used by the binutils and gcc cross-canadian recipes
which package and install the external toolchain binaries into the host
sysroot in the sdk.
Signed-off-by: Christopher Larson <chris_larson@mentor.com>
* general-fixes:
gcc-external{.inc,-cross}: use non-prefixed gcc_binaries
gcc-external.inc: drop unnecessary external-toolchain inherit
layer.conf: add fallback default for GCC_VERSION
gcc: Use globally set GCC_VERSION in recipes
tcmode-external: also blacklist libgfortran
tcmode-external: add prefs for gcc-runtime, libgcc-initial, libgfortran
meta-environment{,-extsdk}: don't include -B${gcc_bindir} in emitted TUNE_CC_ARCH
external-toolchain.bbclass: expand permissions beyond user
libgcc-external: drop the static files that won't be found anyway
libgfortran-external: don't package the static lib and headers
external-toolchain-cross.bbclass: drop sourcery-specific nopseudo handling
oe.external: obey EXTERNAL_FILES over FILES
oe.external: drop unneeded ,True from getVars
external-toolchain.bbclass: stop disabling strip
external-toolchain.bbclass: use PACKAGE_DEPENDS
binutils-external-cross: only link ld.bfd if necessary
This is pulled in already via external-toolchain-cross and
external-toolchain-cross-canadian.
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>
