instead of creating a new package which will only hold the multilib-
link. It would be more appropriate to add the link in the glibc-
external-dev package (as suggested by Chris). With this amendment there
is no need for the bbappend files for core-image-sato core-image-base
and console-image files.
Signed-off-by: adnan-ali1 <adnan_ali@mentor.com>
This link is required by linker to link libraries and crt* files. The
'rm -f' command is changed to 'rm -rf' because in cedar release
external-
toolchain.bbclass copies all the stuff required by PACKAGES to image
folder (in do_install stage). In doing so it copies the architecture
folder (as it is required by FILES_glibc-multilib-link ) from sorcery
folder to image folder in work directory. Afterwords when we try to
remove the directory with 'rm -f' it prompts an error as directories
cannot be deleted with this command.
Signed-off-by: adnan-ali1 <m_adnanali_1@hotmail.com>
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>
