This lets us prefer certain alternative paths to the default in
particular cases, such as use of ${libdir}/bin in the case of a multilib
build to avoid bindir conflicts.
Signed-off-by: Christopher Larson <chris_larson@mentor.com>
* origin/sumo:
external-common.bbclass: fix long standing oe.external import issue
bash: check if support/bash.pc exist before running sed
bash: drop -B${gcc_bindir} from bash.pc
external-toolchain.bbclass: add missing mlprefix in binutils dep
oe.external: handle invalid FILES_MIRRORS entries
glibc-external: add virtual/crypt to PROVIDES
Signed-off-by: Christopher Larson <chris_larson@mentor.com>
bitbake-layers and devtool both fail to run commands with
meta-external-toolchain included, as it fails to import oe.external. It
turns out that oe_import in base.bbclass is not entirely sufficient to
get the needed modules imported when namespace packages are involved,
and those packages have already been imported. Re-import such packages
after the sys.path change to ensure the new __init__.py files are
parsed, and the new __path__ changes picked up.
JIRA: SB-11904
Signed-off-by: Christopher Larson <chris_larson@mentor.com>
When EXTERNAL_TARGET_SYS != TARGET_PREFIX, which is generally the case,
we should ship symlinks with the other prefix. This is largely for
compatibility with existing scripts, but also means we don't need to
alter the variables in environment-setup, i.e. CC.
Signed-off-by: Christopher Larson <chris_larson@mentor.com>
This class will be used by the binutils and gcc cross-canadian recipes
which package and install the external toolchain binaries into the host
sysroot in the sdk.
Signed-off-by: Christopher Larson <chris_larson@mentor.com>
This returns immediately with 'UNKNOWN' if the external toolchain isn't
enabled, and also immediately adjusts sys.path regardless of OE_IMPORTS
handling to avoid the over-reliance upon that mechanism.
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>
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>
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>
Since the external-cross recipes link/wrap the binaries already, there's no
actual need to override TARGET_PREFIX anymore.
Signed-off-by: Christopher Larson <chris_larson@mentor.com>
- Reworked to function the way sanity.bbclass does, rather than running it
every time we do a build
- Add sanity check to test trivial compilation
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>
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>
