From: Daniel Dragomir <daniel.dragomir@windriver.com>
To: openembedded-core@lists.openembedded.org
Subject: [OE-core][PATCH] toolchain-scripts: fix kernel host tool builds broken in the SDK
Date: Mon, 31 Aug 2026 01:49:43 +0300 [thread overview]
Message-ID: <20260830224943.58097-1-daniel.dragomir@windriver.com> (raw)
Building an out-of-tree kernel module with an SDK fails while the kernel is
compiling its own host tools:
$ cd $SDKTARGETSYSROOT/usr/lib/modules/*/build
$ make modules_prepare
...
/usr/include/sys/cdefs.h:486: error: "__attribute_const__" redefined
/usr/include/stdlib.h:219: error: redundant redeclaration of 'strtol'
objtool and the other tools under tools/ ask pkg-config where libelf is, via
HOSTPKG_CONFIG. They are host programs, but the SDK environment sets
PKG_CONFIG_SYSROOT_DIR and PKG_CONFIG_PATH so that pkg-config answers for the
target, and that answer now contains -I/usr/include. Passing /usr/include
explicitly with -I makes the compiler treat those headers as ordinary headers
rather than system headers, so the warnings inside them stop being suppressed
and -Werror turns them into errors.
Ordinary applications built with the SDK are affected too, less visibly: they
pick up a redundant -I$SDKTARGETSYSROOT/usr/include and
-L$SDKTARGETSYSROOT/usr/lib that they never used to get.
Neither the kernel nor the SDK layout changed. What changed is which
pkg-config implementation the SDK ships. pkg-config dropped system
directories such as /usr/include from its answer on its own. pkgconf only
drops them if they are listed in PKG_CONFIG_SYSTEM_INCLUDE_PATH and
PKG_CONFIG_SYSTEM_LIBRARY_PATH, and it compares those lists against paths
that already have the sysroot prepended. So the lists have to hold
sysroot-prefixed paths, and the SDK environment never set them at all.
a3320989ca ("class/pkgconfig: use pkgconf instead of pkgconfig") already
sysroot-prefixed both variables for the build environment, in
pkgconfig.bbclass. Do the same for the SDK environment.
Checked with pkgconf 2.5.1 on a .pc file inside a sysroot, with
PKG_CONFIG_SYSROOT_DIR set:
before: -I$S/usr/include -I$S/usr/include/bsd-1.0 -L$S/usr/lib -lbsd
after: -I$S/usr/include/bsd-1.0 -lbsd
which is what pkg-config used to return for the same input.
The native sysroot directories are listed as well. Setting either variable
replaces pkgconf's built-in list instead of adding to it, and for
nativesdk-pkgconf that built-in list is what currently keeps nativesdk .pc
files from leaking their own -I and -L into host tool builds.
toolchain_create_tree_env_script() is left alone: it already passes an unset
$libdir and $prefix to its own PKG_CONFIG_PATH line, so it needs a separate
look.
Assisted-by: kiro:claude-opus-5
Signed-off-by: Daniel Dragomir <daniel.dragomir@windriver.com>
---
meta/classes-recipe/toolchain-scripts.bbclass | 2 ++
1 file changed, 2 insertions(+)
diff --git a/meta/classes-recipe/toolchain-scripts.bbclass b/meta/classes-recipe/toolchain-scripts.bbclass
index 5bdf22dfa2..e971b9a270 100644
--- a/meta/classes-recipe/toolchain-scripts.bbclass
+++ b/meta/classes-recipe/toolchain-scripts.bbclass
@@ -63,6 +63,8 @@ toolchain_create_sdk_env_script () {
echo "export PATH=$sdkpathnative$bindir:$sdkpathnative$sbindir:$sdkpathnative$base_bindir:$sdkpathnative$base_sbindir:$sdkpathnative$bindir/../${HOST_SYS}/bin:$sdkpathnative$bindir/${TARGET_SYS}"$EXTRAPATH':"$PATH"' >> $script
echo 'export PKG_CONFIG_SYSROOT_DIR=$SDKTARGETSYSROOT' >> $script
echo 'export PKG_CONFIG_PATH=$SDKTARGETSYSROOT'"$libdir"'/pkgconfig:$SDKTARGETSYSROOT'"$prefix"'/share/pkgconfig' >> $script
+ echo 'export PKG_CONFIG_SYSTEM_INCLUDE_PATH=$SDKTARGETSYSROOT'"$prefix"'/include:'"$sdkpathnative${includedir_nativesdk}" >> $script
+ echo 'export PKG_CONFIG_SYSTEM_LIBRARY_PATH=$SDKTARGETSYSROOT'"$libdir"':$SDKTARGETSYSROOT/${baselib}:'"$sdkpathnative${libdir_nativesdk}" >> $script
echo 'export CONFIG_SITE=${SDKPATH}/site-config-'"${multimach_target_sys}" >> $script
echo "export OECORE_NATIVE_SYSROOT=\"$sdkpathnative\"" >> $script
echo 'export OECORE_TARGET_SYSROOT="$SDKTARGETSYSROOT"' >> $script
--
2.43.0
reply other threads:[~2026-08-30 22:50 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20260830224943.58097-1-daniel.dragomir@windriver.com \
--to=daniel.dragomir@windriver.com \
--cc=openembedded-core@lists.openembedded.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox