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>
Since we're running cp -p to preserve other aspects, we need to manually
correct the ownership to what we expect (root:root) rather than the current
ownership.
JIRA: SB-4185
Signed-off-by: Christopher Larson <kergoth@gmail.com>
We want the path included in the checksums for the -external-cross recipes, as
they wrap the external binaries and hardcode that path, but we don't want it
included in the checksums for anything else, and we don't want rebuilding the
external-cross recipes to cause rebuilds of thing sthat depend upon them.
Signed-off-by: Christopher Larson <kergoth@gmail.com>
