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>
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>
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>
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>
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>
buildtools-tarball is host only, and does not add TOOLCHAIN_TARGET_TASK to
RDEPENDS. Forcibly empty it, otherwise a TOOLCHAIN_TARGET_TASK_append at the
config level will break the buildtools-tarball build
JIRA: SB-8391
Signed-off-by: Christopher Larson <chris_larson@mentor.com>
Since the external toolchain is available at parse time, we can actually grab
the kernel version from the external toolchain sysroot and use that to
determine whether to apply the patch. Do so.
Signed-off-by: Christopher Larson <chris_larson@mentor.com>
A patch in oe-core is needed, at this time, to fix builds with
linux-libc-headers from the 4.8 Linux kernel or newer, which is not the case
for most external toolchains. Unfortunately, this patch also breaks the build
of ppp with older linux-libc-headers, so we need to revert it. A note in the
README is added explaining how to disable this for external toolchains with
recent enough kernel libc headers.
Signed-off-by: Christopher Larson <chris_larson@mentor.com>
Avoid providing "gdbserver" if PREFERRED_PROVIDER is set to
external-sourcery or some other package which also provides it. This
avoids "Multiple Provider" warnings.
Signed-off-by: Drew Moseley <drew_moseley@mentor.com>
Due to a previous workaround, the external gcc/g++ is run outside of pseudo
context. The ncurses install target re-links the libraries directly into ${D},
so we need to make sure the ownership on those files is correct.
JIRA: SB-4185
Signed-off-by: Christopher Larson <kergoth@gmail.com>
common-license.bbclass will set LIC_FILES_CHKSUM to a common license file
based on LICENSE, which is appropriate for a case where we have no sources to
refer to.
external-toolchain.bbclass, among other things, handles extraction of files in
the external toolchain sysroot, based on patterns in the FILES variables,
checking alternate locations to better support any arbitrary toolchain, and
has basic mirror handling for checking multiple paths within the sysroots.
Under normal circumstances, I'd want this to use highly granular commits, but
this branch has been extremely long lived (>1yr) and is such an invasive
refactoring that attempting to break it down now would be of limited
usefulness.
Signed-off-by: Christopher Larson <chris_larson@mentor.com>
