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>
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>
