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>
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>
Currently the substitutions fail to match if the path contains re
special characters like '+', which is problematic.
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>
This will install, for example, a 'ld.gold' symlink in
STAGING_BINDIR_TOOLCHAIN/gcc, which we can then allow gcc to get to.
This makes it possible to rebuild just binutils-cross and use everything
else from an external toolchain, which can be useful to get ahold of
ld.gold when the external toolchain doesn't provide it.
Signed-off-by: Christopher Larson <chris_larson@mentor.com>
This ensures that _append/_prepend/_remove are also applied, so the user
can remove elements from the variable.
Signed-off-by: Christopher Larson <chris_larson@mentor.com>
We need to disable this for the same reason we disable the build-deps check.
The recursive dependency between libgcc and glibc has to be broken.
Signed-off-by: Christopher Larson <chris_larson@mentor.com>
Silence any errors from oe_multilib_header, as we don't care about missing
multilib headers, as the oe-core glibc version isn't necessarily the same as
our own.
Signed-off-by: Christopher Larson <chris_larson@mentor.com>
Align TARGET_SYS and TARGET_PREFIX to avoid binary links which include both:
WARNING: gcc-6.2.0-r0 do_package: QA Issue: gcc: Files/directories were installed but not shipped in any package:
/usr/bin/arm-mel-linux-gnueabi-arm-none-linux-gnueabi-gcc-nm
/usr/bin/arm-mel-linux-gnueabi-arm-none-linux-gnueabi-gcc
/usr/bin/arm-mel-linux-gnueabi-arm-none-linux-gnueabi-gcc-ranlib
/usr/bin/arm-mel-linux-gnueabi-arm-none-linux-gnueabi-g++
/usr/bin/arm-mel-linux-gnueabi-arm-none-linux-gnueabi-gcc-ar
Moved from meta-mentor.
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 layer focuses on new recipes, so make it clear where the appends are by
isolating them, even for oe-core.
Signed-off-by: Christopher Larson <chris_larson@mentor.com>
This layer focuses on new recipes, so make it clear where the appends are by
isolating them, even for oe-core.
Signed-off-by: Christopher Larson <chris_larson@mentor.com>
