From: Daniel Dragomir <daniel.dragomir@windriver.com>
To: "openembedded-core@lists.openembedded.org"
<openembedded-core@lists.openembedded.org>
Subject: [wrynose][SDK] kernel-devsrc: objtool build fails in SDK - works in scarthgap
Date: Thu, 2 Jul 2026 16:06:22 +0300 [thread overview]
Message-ID: <0c44eae7-77d9-4375-8fef-704e5fda2d1f@windriver.com> (raw)
Hi all,
I'm hitting a build failure when trying to build out-of-tree kernel
modules using the SDK generated from Wrynose. The same workflow works
fine with Scarthgap.
Steps to reproduce (genericx86-64 machine and 6.18.24-yocto-standard):
1. IMAGE_INSTALL:append = " kernel-devsrc" in local.conf
2. bitbake core-image-sato-sdk -c populate_sdk
3. Install and source the SDK
4. cd $SDKTARGETSYSROOT/usr/lib/modules/6.18.24-yocto-standard/build
5. make modules_prepare
It fails because make modules_prepare triggers objtool build, and
objtool (host tool) picks up the target sysroot headers instead of the
native host headers.
DESCEND objtool
CC .../build/tools/objtool/libsubcmd/exec-cmd.o
.../usr/include/sys/cdefs.h:486: error: "__attribute_const__" redefined
[-Werror]
486 | # define __attribute_const__ __attribute__ ((__const__))
.../build/tools/include/linux/compiler.h:123: note: this is the location
of the previous definition
123 | # define __attribute_const__
There are also many -Werror=redundant-decls errors from glibc's stdlib.h
(strtol, strtoul, strtoq, strtouq, strtoll, and others), for example:
.../usr/include/stdlib.h:219:33: error: redundant redeclaration of
'strtol' [-Werror=redundant-decls]
219 | extern long int __REDIRECT_NTH (strtol, (const char *__restrict
__nptr,
| ^~~~~~
A workaround is to unset PKG_CONFIG_SYSROOT_DIR variable which is set by
the SDK env file to $SDKTARGETSYSROOT.
This makes objtool compile successfully, but I'm afraid this may break
userspace application compilation that relies on PKG_CONFIG_SYSROOT_DIR
to find libraries in the target sysroot. So the variable needs to be
restored (or the environment re-sourced) before building applications.
Is this a regression compared to Scarthgap where the same flow works
without issues? Has anyone else encountered this?
Thanks,
Daniel
reply other threads:[~2026-07-02 13:06 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=0c44eae7-77d9-4375-8fef-704e5fda2d1f@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