Bug 15982

Summary:	yocto-check-layer doesn't work with multiconfig/baremetal machines
Product:	[Build System, Metadata & Runtime] OE-Core	Reporter:	Denys Dmytriyenko <denis>
Component:	Scripts and Tools	Assignee:	Denys Dmytriyenko <denis>
Status:	NEW ---	QA Contact:
Severity:	normal
Priority:	Medium+	CC:	paul, randy.macleod, ross.burton
Version:	unspecified
Target Milestone:	6.1 M2
Hardware:	All
OS:	Multiple
Whiteboard:
OS type for building Yocto:	---	Type of Regression:	---
Verified:		Documentation change:	Don't know

Description Denys Dmytriyenko 2025-09-27 16:19:51 UTC

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.

Comment 1 Denys Dmytriyenko 2025-09-27 20:09:34 UTC

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.

Comment 2 Denys Dmytriyenko 2025-09-27 23:26:13 UTC

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

Comment 3 Denys Dmytriyenko 2025-10-02 00:13:36 UTC

Promised RFC series:
https://patchwork.yoctoproject.org/project/oe-core/list/?series=38812

Comment 4 Randy MacLeod 2026-04-15 20:09:24 UTC

I think Paul updated yocto-check-layer.
Paul, Denys,
  Is this still broken?

Comment 5 Denys Dmytriyenko 2026-04-15 20:42:20 UTC

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

Comment 6 Randy MacLeod 2026-04-16 15:26:48 UTC

Thanks Denys,

Discussed in YP bug review and I think the ball is in your court
with Paul's help if needed.