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>
This link is required by linker to link libraries and crt* files in our
ADE/SDK. The 'rm -f' command is changed to 'rm -rf' because
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_${PN}-dev ) from sourcery 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 <adnan_ali@mentor.com>
Signed-off-by: Christopher Larson <chris_larson@mentor.com>
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>
