[wrynose][SDK] kernel-devsrc: objtool build fails in SDK - works in scarthgap

[wrynose][SDK] kernel-devsrc: objtool build fails in SDK - works in scarthgap

[Daniel Dragomir]

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