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>
Ensure -m32/-m64 are passed for EFI, as the buildsystem currently relies on
the default for the toolchain, which isn't necessarily correct for an external
toolchain.
Signed-off-by: Christopher Larson <chris_larson@mentor.com>
We don't need or want this dep, so set it to the empty string rather than
including gcc-common.inc. This fixes builds with current upstream master.
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>
This reverts commit 91b3032784.
We need these explicitly listed in order to ensure we don't just package the
files, but extract them from the sysroot. The best approach would be to
identify elf binaries the way package.bbclass does, and extract the
debuglink path to determine the files to include, but that can be a future
enhancement.
JIRA: SB-8524
Signed-off-by: Christopher Larson <chris_larson@mentor.com>
