Sourcery codebench toolchain for aarch64 architecture doesn't have
libatomic available which causes ade build failure. Drop the
dependency on libatomic for aarch64 based xilinx MPSoC target.
JiraID: ITS-50
Signed-off-by: Yasir-Khan <yasir_khan@mentor.com>
It's useful to know which target triplet/system was selected by the logic in
the tcmode file, as it searches EXTERNAL_TOOLCHAIN to determine which to use.
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>
- 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>
