Since external recipes don't require virtual/libc and the compilerlibs, we
won't always get our rdeps on those from the shlibs processing, unless we
depend on the packagedata from those recipes. Adding them to DEPENDS would
have worked too, but would have been a lie in a sense, as we don't actually
require those to "build", just package.
Signed-off-by: Christopher Larson <kergoth@gmail.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>
Due to a previous workaround, the external gcc/g++ is run outside of pseudo
context. The ncurses install target re-links the libraries directly into ${D},
so we need to make sure the ownership on those files is correct.
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>
- Move from BuildStarted time to TreeDataPreparationStarted, as we want
bitbake -e to work, so it has to run after ConfigParsed, and we want to see
these errors rather than the highly verbose unbuildable -external recipe
errors which occur when generating the runqueue, so we need to run before
BuildStarted.
- Add 'does gcc exist' sanity test. This also shows an informative warning if
the bindir exists, but the gcc binary doesn't, and EXTERNAL_TARGET_SYS ==
TARGET_SYS, which indicates we failed to find a prefix via
EXTERNAL_TARGET_SYSTEMS.
- Add 'is GCC_VERSION UNKNOWN' sanity test, mentioning the failure of gcc
version extraction, and pointing to the debug messages to see what actually
happened.
JIRA: SB-4850, SB-1029
Signed-off-by: Christopher Larson <kergoth@gmail.com>
While these messages are useful when debugging, the warnings clutter up the
log due to running before our sanity checks, potentially confusing the user.
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>
We only care about the resulting value of EXTERNAL_TARGET_SYS, not the
components that fed into it.
Signed-off-by: Christopher Larson <kergoth@gmail.com>
This is more a distro/user decision, I think, so move it there. Also this was
insufficient, as just removing `packagegroup-cross-canadian-${MACHINE}` without
adding back in `meta-environment-${MACHINE}` results in an sdk which hangs on
install.
Signed-off-by: Christopher Larson <kergoth@gmail.com>
common-license.bbclass will set LIC_FILES_CHKSUM to a common license file
based on LICENSE, which is appropriate for a case where we have no sources to
refer to.
external-toolchain.bbclass, among other things, handles extraction of files in
the external toolchain sysroot, based on patterns in the FILES variables,
checking alternate locations to better support any arbitrary toolchain, and
has basic mirror handling for checking multiple paths within the sysroots.
Under normal circumstances, I'd want this to use highly granular commits, but
this branch has been extremely long lived (>1yr) and is such an invasive
refactoring that attempting to break it down now would be of limited
usefulness.
Signed-off-by: Christopher Larson <chris_larson@mentor.com>
