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>
- If the user set EXTERNAL_TOOLCHAIN to the top of the CodeBench install
rather than the actual toolchain path, we correct it
- If the user set EXTERNAL_TOOLCHAIN to the path to a new CodeBench, where the
toolchains are installed elsewhere, set CODEBENCH_PATH instead, so we
correctly and automatically set EXTERNAL_TOOLCHAIN
When these fixups are performed, warnings are displayed, indicating the
correct values for the variables, so the user can set them that way if we they
want to silence the warnings.
JIRA: SB-7881
Signed-off-by: Christopher Larson <chris_larson@mentor.com>
If the user hasn't set EXTERNAL_TOOLCHAIN, but CODEBENCH_PATH is set, then we
automatically set both EXTERNAL_TOOLCHAIN and EXTERNAL_TARGET_SYS based on the
installed toolchains in CODEBENCH_PATH/../toolchains.
This adds a new variable, rather than allowing EXTERNAL_TOOLCHAIN to point to
CodeBench instead of the actual toolchain path, to keep the clean separation
between the generic toolchain logic and that which is specific to our
toolchains, and also avoids overloading the variable's meaning.
JIRA: SB-7881
Signed-off-by: Christopher Larson <chris_larson@mentor.com>
If multiple are available, the 'mentor' triplets are preferred, as that's the
non-lite toolchain. Sort them so those are first, as we stop at the first one
we find.
Signed-off-by: Christopher Larson <chris_larson@mentor.com>
libssp_nonshared.a is installed by gcc-runtime-external so
glibc-external should not install this into a shared area when
it already exists.
Signed-off-by: Fahad Arslan <Fahad_Arslan@mentor.com>
This phrase implies knowledge of the build process or the layer history which
is not always the case.
Signed-off-by: Christopher Larson <chris_larson@mentor.com>
Files are packaged which need libc libraries, so we need the packagedata so
shlibs can find them.
Signed-off-by: Christopher Larson <chris_larson@mentor.com>
oe.path.check_output was returning a bytes, not an str. Switch to bb.process
to resolve issues with python3.
Signed-off-by: Christopher Larson <chris_larson@mentor.com>
* origin/cedar:
tcmode-external-sourcery: Add MGLS_LICENSE_FILE if not found in environment
Signed-off-by: Christopher Larson <chris_larson@mentor.com>
There's no reason not to make use of it, and it's used by default with the
internal toolchain, so this aligns us closer to that.
Signed-off-by: Christopher Larson <chris_larson@mentor.com>
Old messages:
WARNING: EXTERNAL_TARGET_SYS == TARGET_SYS. This indicates that the prefixes specified by EXTERNAL_TARGET_SYSTEMS were not found.
ERROR: EXTERNAL_TOOLCHAIN gcc path '<external-toolchain>/bin/arm-mel-linux-gnueabi-gcc' does not exist
New message:
ERROR: Unable to locate prefixed gcc binary for arm-mel-linux-gnueabi in <external-toolchain>/bin
Signed-off-by: Christopher Larson <chris_larson@mentor.com>
This alters the vars for the cross-compiler, not the build tools, so this is
most appropriate, and is one less thing to have in TOOLCHAIN_HOST_TASK.
Signed-off-by: Christopher Larson <chris_larson@mentor.com>
This is a script -- we don't want to suck in the toolchain. I thought about
also pulling in allarch, but I don't know how that interacts with nativesdk
yet.
Signed-off-by: Christopher Larson <chris_larson@mentor.com>
