These were obsolete bits removed from the glibc recipe in oe-core, and
are provided both in another recipe, and, better yet, libtirpc.
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>
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>
