Complimentary to https://bugzilla.yoctoproject.org/show_bug.cgi?id=15974 Some layers, like meta-ti-bsp, define machines that enable TCLIBC="baremetal" multiconfig to build a few extra components - those components run on MCU core, not the main CPU, and required for boot. If --machine is passed to yocto-check-layer, it will try to "build" world (collect signatures) for all multiconfigs enabled by that machine, resulting in many failures due to world incompatibility with "baremetal" settings. While some incompatibilities like kernel can be resolved/bypassed with PREFERRED_PROVIDER_virtual/kernel="linux-dummy" in that multiconfig, there are still some weird dependency loops around toolchain and base tools. Also this: ERROR: Nothing PROVIDES 'newlib' (but mc:k3r5:/OE/master/sources/oe-core/meta/recipes-core/newlib/libgloss_git.bb DEPENDS on or otherwise requires it) newlib was skipped: PREFERRED_PROVIDER_virtual/libc set to musl, not newlib ERROR: Required build target 'meta-world-pkgdata' has no buildable providers. Missing or unbuildable dependency chain was: ['meta-world-pkgdata', 'libgloss', 'newlib'] We have previously discussed this and agreed that correcting each and every occurrence (like libgloss above) is not right.
BTW, in order to use linux-dummy to bypass many virtual/kernel dependencies during baremetal world signature dump (instead of adding conditions to all those dependent recipes), linux-dummy also shouldn't be restricted to Linux-only hosts by removing COMPATIBLE_HOST=".*-linux" which I don't know if correct or cause any side effects. Anyway, I've got several additional fixes to address incompatibilities with baremetal world build - I'll try to submit an RFC series shortly for review and comments. But I still get a dependency loop in there which I haven't been able to resolve yet - I'll post logs here later.
And FTR, I did try approaching kernel dependencies in baremetal world build individually, but that's not limited to virtual/kernel only, think of all the kernel-related dependencies, like makemod, different device trees and a lot of RRECOMMENDS for individual kernel modules for subsystems like networking/connectivity, buses/protocols, filesystems and HW drivers, etc. Those are sprinkled across many components, but also exist in large numbers in base/core packagegroups. So, I'm still leaning towards RFC-ing the linux-dummy shortcut...
Promised RFC series: https://patchwork.yoctoproject.org/project/oe-core/list/?series=38812
I think Paul updated yocto-check-layer. Paul, Denys, Is this still broken?
Yes, it is most certainly is. We've been discussing this at the TSC recently. I will need to do another round of this, but right now it got broken in another place, specifically at the first use case of https://bugzilla.yoctoproject.org/show_bug.cgi?id=12688
Thanks Denys, Discussed in YP bug review and I think the ball is in your court with Paul's help if needed.