Re: [OE-core] [PATCH 2/2] toolchain-scripts, oeqa/sdk: build the kernel's host tools with a host pkg-config

[Trevor Woerner <twoerner@gmail.com>]

On Thu 2026-08-13 @ 03:04:04 PM, Richard Purdie wrote:
> On Wed, 2026-08-05 at 02:57 -0400, Trevor Woerner via lists.openembedded.org wrote:
> > The SDK environment sets PKG_CONFIG_SYSROOT_DIR, PKG_CONFIG_PATH and
> > PKG_CONFIG_LIBDIR so that pkg-config answers for the target. That is
> > right for everything built to run there and wrong for a program built to
> > run on the SDK host.
> > 
> > The kernel build compiles host tools of its own, and objtool asks
> > pkg-config where libelf is. It gets the target's include directory,
> > compiles a host tool against the target's C library headers, and stops
> > on warnings that -Wno-system-headers would otherwise have covered:
> > 
> >   usr/include/sys/cdefs.h:486: error: "__attribute_const__" redefined
> > 
> > Export a HOSTPKG_CONFIG that undoes those three variables, and pass the
> > same value on the make command line when the test builds an external
> > module. Both halves are needed: the kernel assigns HOSTPKG_CONFIG with
> > '=', so only a command line assignment takes effect today, and the
> > export is there for kernels that assign it with '?=', which is proposed
> > in
> > 
> >   https://lore.kernel.org/linux-kbuild/20260805055438.3482019-1-twoerner@gmail.com/
> > 
> > OE-Core already does the command line half for its own kernel builds, in
> > kernel.bbclass.
> > 
> > Fixes [YOCTO #16239].
> > 
> > AI-Generated: codex/claude-opus 5 (xhigh)
> > Signed-off-by: Trevor Woerner <twoerner@gmail.com>
> > ---
> >  meta/classes-recipe/toolchain-scripts.bbclass | 3 +++
> >  meta/lib/oeqa/sdk/cases/kmod.py               | 7 +++++--
> >  2 files changed, 8 insertions(+), 2 deletions(-)
> 
> The kmod test piece of this is probably ok, as you say, we do that in
> the kernel classes. I do note that the kernel class redirects to a pkg-
> config wrapper and perhaps the kmod class should match, rather than
> doing something different though?

Agreed. I just sent a v3 that does that, so the test now passes the same
wrapper rather than spelling it out.

> The toolchain piece is a but more of a concern since we're encoding
> kernel specific variables into the generic toolchain environment file
> and in general we don't want to do recipe specific things there...

Yes, and it is dropped. My v2 crossed with this email and already does
this.

> Cheers,
> 
> Richard