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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.