* 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>
- 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>
Also provide external-common.bbclass to wrap its inclusion and setup
associated metadata. This will make easier to search sysroots for files
without pulling in the rest of the external toolchain class.
Signed-off-by: Christopher Larson <chris_larson@mentor.com>
The skip message shows all the paths we're searching for, and it's bloated
with a ton of .debug entries, so remove them, we don't care about them in this
context anyway.
Signed-off-by: Christopher Larson <chris_larson@mentor.com>
Check for files outside of /home which are owned by the user running bitbake.
Add `package_qa_sourcery` to `PACKAGE_CLASSES`, and `${SOURCERY_QA}` to your
`WARN_QA` or `ERROR_QA` to use.
This will be submitted to oe-core's package_qa.
JIRA: SB-4185
Signed-off-by: Christopher Larson <kergoth@gmail.com>
