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>
The external toolchain currently has a different naming scheme than any of
oe-core's currently hardcoded schemes, so failed to recognize the files as
debug, and would add debuglinks to the debug files, which is obviously wrong.
Signed-off-by: Christopher Larson <chris_larson@mentor.com>
We drop the overly greedy patterns for libm* and *_nonshared and explicitly
add back the bits we know we own, but libmvec was missing from this.
Signed-off-by: Christopher Larson <chris_larson@mentor.com>
This overly greedy pattern was picking up, via the FILES_MIRRORS, the
nonshared paths in ${libdir}.
Signed-off-by: Christopher Larson <chris_larson@mentor.com>
We don't want the 'libm*.so.*' kept in our FILES, as it's too greedy, and
results in picking up the wrong things.
Signed-off-by: Christopher Larson <chris_larson@mentor.com>
If the EXTERNAL_TOOLCHAIN path doesn't exist, the error logic had a variable
name issue (extdir vs extpath). Fix.
Signed-off-by: Christopher Larson <chris_larson@mentor.com>
