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>
We only want this to take effect for the locales for the external toolchain,
not those generated and used for nativesdk, otherwise we break the
buildtools-tarball build.
JIRA: SB-8391
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>
Using the one already available with our toolchain makes a great deal of
sense, as it's a known quantity. The only reason we switched to gdb was due to
conflicts between gdb and gdbserver-external, but that issue has been
resolved.
Signed-off-by: Christopher Larson <chris_larson@mentor.com>
libssp support is only available in toolchain for minnowmax so
remove it until there is a requirement.
Jira ID: SB-8337
Signed-off-by: Fahad Arslan <Fahad_Arslan@mentor.com>
It's not ideal to do this for every build, but it's not terrible, either, and
is worth the cost to get an error up front if there's a configuration or
licensing problem. master deals with this more cleanly.
JIRA: SB-8257
Signed-off-by: Christopher Larson <chris_larson@mentor.com>
We were hitting issues due to non-deterministic ordering of ConfigParsed event
handlers between codebench.bbclass and the tcmode. To avoid this, consolidate
the two and use a single handler.
Signed-off-by: Christopher Larson <chris_larson@mentor.com>
If we run in tmpdir, and run a bitbake -e after wiping tmpdir,
EXTERNAL_TOOLCHAIN_SYSROOT will be 'UNKNOWN' rather than the correct path, due
to PWD not existing when we try to extract the sysroot path.
Signed-off-by: Christopher Larson <chris_larson@mentor.com>
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>
