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>
Files are packaged which need libc libraries, so we need the packagedata so
shlibs can find them.
Signed-off-by: Christopher Larson <chris_larson@mentor.com>
There's no need to override this, the default packages is fine, and we already
rprovides the non-external-suffixed package names. This would also have caused
breakage for multilib builds, as the specified package names in PACKAGES
didn't include MLPREFIX.
Signed-off-by: Christopher Larson <chris_larson@mentor.com>
This aligns with the non-external recipe, and as ${PN}-dev already disables
the staticdev QA check, this also silences the libgcov-dev QA warning. We
could also have changed libgcov-dev to ${MLPREFIX}libgcov-dev.
JIRA: SB-6225
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>
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>
