After populating the SDK with kernel sources, running 'make scripts/prepare' fails during the build process. Steps to Reproduce: 1)Populate SDK with kernel sources TOOLCHAIN_TARGET_TASK:append = " kernel-dev kernel-devsrc" 2)source the sdk environment. 3))Navigate to kernel build directory 4)Run: 'make scripts prepare' Example Error: error: "__attribute_const__" redefined [-Werror] note: previous definition is in linux/compiler.h error: redundant redeclaration of ‘strtol’ [-Werror=redundant-decls]
Harish, Does this only happen with Rust ? Can you attach the full compiler error log? Why don't we see this in a YP AB test ? Do we need a new test ?
Created attachment 5207 [details] Full build log for make scripts/prepare failure showing header redefinition and redundant declaration errors in sdk
I have attached the complete build failure log. This issue occurs even when Rust support is not enabled. At the moment, I don’t see any existing test case that covers this scenario. I think it will be better if there is a test, I'll plan to investigate further on creating a suitable test case for it.
Harish, Thanks for the explaination. Please work on this for 6.1.
The cause is pkg-config being answered for the target while a host tool is built. objtool asks pkg-config where libelf is [1], and in an SDK environment PKG_CONFIG_SYSROOT_DIR makes it answer for the target, so -I$SDKTARGETSYSROOT/usr/include lands on a host compile. That -I is why the warnings become errors: the libc headers are no longer system headers, so -Wno-system-headers stops covering them. Fix, tested: make HOSTPKG_CONFIG="env -u PKG_CONFIG_SYSROOT_DIR -u PKG_CONFIG_PATH \ -u PKG_CONFIG_LIBDIR pkg-config" \ -C $OECORE_TARGET_SYSROOT/usr/src/kernel prepare scripts kernel.bbclass already does this for OE's own kernel builds with HOSTPKG_CONFIG="pkg-config-native" [2]; the SDK has no equivalent. It must be a make command line assignment, since the kernel sets HOSTPKG_CONFIG with '=' [3]. Behind it is a second, unrelated failure: the cryptodev revision oeqa pins predates the removal of crypto_ahash_alignmask(). Upstream's 08644db02d43 fixes that [4]. With both changes kmod.KernelModuleTest.test_cryptodev passes, on oe-core master 6a91494f29a1, qemux86-64, linux-yocto 6.18.39, glibc 2.44, gcc 16.1. On comments #1 and #3: the test already exists [5] and it skips everywhere. In yocto-testresults at "Results of master:6a91494f29a1" it is SKIPPED in all twenty SDK result sets [6], while gcc, perl and python pass in the same runs. Nothing puts kernel-devsrc into an autobuilder SDK. It is x86 specific rather than 6.18 specific, which is probably how it survived: arm64 does not select HAVE_OBJTOOL [7], and libelf.pc only reaches the sysroot because kernel-devsrc pulls elfutils-dev on x86 and powerpc [8]. I also have a tested one line kernel patch making HOSTPKG_CONFIG '?=', which lets the SDK environment simply export it; every other HOST* input is already environment-settable and documented in kbuild.rst [9]. Happy to send that to the kbuild list, and the kmod.py changes as a standalone patch, if that is more useful than waiting for the series they are in. [1] tools/objtool/Makefile, LIBELF_FLAGS https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/tools/objtool/Makefile?h=v6.18#n21 [2] meta/classes-recipe/kernel.bbclass, HOSTPKG_CONFIG="pkg-config-native" https://git.openembedded.org/openembedded-core/tree/meta/classes-recipe/kernel.bbclass [3] Linux Makefile, HOSTPKG_CONFIG = pkg-config https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Makefile?h=v6.18#n459 [4] cryptodev-linux, "Fix build for Linux 6.18-rc1" https://github.com/cryptodev-linux/cryptodev-linux/commit/08644db02d43478f802755903212f5ee506af73b [5] meta/lib/oeqa/sdk/cases/kmod.py https://git.openembedded.org/openembedded-core/tree/meta/lib/oeqa/sdk/cases/kmod.py [6] yocto-testresults, sdk/ https://git.yoctoproject.org/yocto-testresults/tree/sdk [7] arch/x86/Kconfig, select HAVE_OBJTOOL if X86_64 https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/x86/Kconfig?h=v6.18#n272 [8] meta/recipes-kernel/linux/kernel-devsrc.bb, elfutils-dev RDEPENDS https://git.openembedded.org/openembedded-core/tree/meta/recipes-kernel/linux/kernel-devsrc.bb [9] Documentation/kbuild/kbuild.rst https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/kbuild/kbuild.rst?h=v6.18
The kernel patch offered in comment #5 is now posted to the kbuild list: kbuild: let the environment set HOSTPKG_CONFIG https://lore.kernel.org/linux-kbuild/20260805055438.3482019-1-twoerner@gmail.com/ It makes the assignment '?=' and documents HOSTPKG_CONFIG in kbuild.rst beside HOSTCFLAGS, HOSTCXXFLAGS, HOSTLDFLAGS and HOSTLDLIBS, which are all environment-settable already. An SDK can then export it once in the shell it hands the user instead of every make command line growing an override. The OE-Core side does not wait on that. It is posted as its own two-patch series rather than buried in the SDK_FEATURES work it was found in: fix the SDK kernel module test https://lore.kernel.org/openembedded-core/20260805065718.3497815-1-twoerner@gmail.com/ https://patchwork.yoctoproject.org/project/oe-core/list/?series=49547 1/2 oeqa/sdk: update cryptodev to a revision that builds on kernel 6.18 2/2 toolchain-scripts, oeqa/sdk: build the kernel's host tools with a host pkg-config The second carries both halves of the fix. The SDK environment script exports HOSTPKG_CONFIG, and the kernel module test passes the same value on the make command line. Both are needed, for different reasons: only the command line assignment has any effect today, because the kernel still assigns HOSTPKG_CONFIG with '=', while the export starts working wherever the kbuild patch above is present, and covers someone building a module by hand rather than through the test. Nothing in either patch depends on the kernel change being accepted. If it is rejected the export is dead weight and should be dropped, leaving the command line assignment, which is what kernel.bbclass already does for OE's own kernel builds. Status here: with both patches applied, test_cryptodev passed on qemux86-64 with the configuration given in comment #5. Without them it still fails in an SDK built from current master.
Comment #6 offered a kernel patch, and predicted what should happen to the OE-Core series if that patch were rejected. Both have now resolved, in the same direction. THE KERNEL PATCH IS ABANDONED Nicolas Schier, and then independently Nathan Chancellor, made the same objection: HOSTPKG_CONFIG belongs with HOSTCC, HOSTCXX and HOSTRUSTC, which all use '=' and deliberately do not honour an environment value, rather than with HOSTCFLAGS and the other flag variables I compared it to. That comparison was the load-bearing part of my argument and it was wrong. The flag variables are never assigned at all, only consumed: KBUILD_HOSTCFLAGS := $(KBUILD_USERHOSTCFLAGS) $(HOST_LFS_CFLAGS) \ $(HOSTCFLAGS) -I $(srctree)/scripts/include so they honour the environment by construction, which is a different mechanism from the one I proposed. https://lore.kernel.org/linux-kbuild/178614091702.32781.13796520858880316981.b4-review@b4/ I am not pursuing the patch. Nothing on the OE-Core side depended on it. MAKEFLAGS ALREADY DOES THE JOB, WITH NO KERNEL CHANGE Nathan also suggested MAKEFLAGS, and it works. Measured on linux-yocto 6.18 with O= set, so the kernel's top-level re-exec is in play, which is what defeats most attempts at this: HOSTPKG_CONFIG='env -u ... pkg-config' make ignored MAKEFLAGS='HOSTPKG_CONFIG=env\ -u\ ...' make works make 'HOSTPKG_CONFIG=env -u ... pkg-config' ... works THE SPACES INSIDE THE MAKEFLAGS VALUE MUST BE BACKSLASH-ESCAPED. Unescaped, the value silently truncates at the first space, the build fails exactly as originally reported, and nothing points at the cause. So anyone who wants this set once for a shell, rather than on every make command line, can have it today with no kernel change. The value to use is the one in comment #5. That is deliberately NOT what the SDK environment script does. Exporting MAKEFLAGS reaches every make the user runs in that shell, which is a larger decision than this bug needs. THE OE-CORE FIX, NOW AT v2 Comment #6 said that if the kernel patch were rejected, the environment export would be dead weight and should be dropped, leaving the make command line assignment. That is what v2 does. fix the SDK kernel module test, v2 https://patchwork.yoctoproject.org/project/oe-core/list/?series=49822 1/2 oeqa/sdk: update cryptodev to a revision that builds on kernel 6.18 2/2 oeqa/sdk: build the kernel's host tools with a host pkg-config The SDK environment script now exports no HOSTPKG_CONFIG at all. The second patch touches only meta/lib/oeqa/sdk/cases/kmod.py, and its subject lost the toolchain-scripts prefix accordingly. The series is seven insertions and four deletions, in that one file. With it applied, kmod.KernelModuleTest.test_cryptodev passes in the configuration given in comment #5. Neither patch has landed: master at dd003e147db5 still pins the cryptodev revision that does not build against 6.18, and still builds the kernel's host tools with the SDK's target-facing pkg-config. Both patches are under review.
I have a patch for this which will hopefully be sent for review this upcoming week.
Both patches are now on master: 7d37b28073a1 oeqa/sdk: update cryptodev to a revision that builds on kernel 6.18 7e5fedde6afc oeqa/sdk: build the kernel's host tools with a host pkg-config Between them they touch only meta/lib/oeqa/sdk/cases/kmod.py, and they address what was reported here: the pinned cryptodev revision now builds against 6.18, and the kernel's host tools are built with a host pkg-config instead of the SDK's target-facing one. Leaving this open, because the fix is not yet exercised anywhere. The test still guards on self.ensure_target_package("kernel-devsrc") and a standard SDK does not install kernel-devsrc, so the case skips rather than runs. A green autobuilder therefore still says nothing about this code path. I do have a patch for that half of it. It adds a kernel-src SDK feature whose target package is, as it stands, kernel-devsrc, so an SDK can be asked to ship the kernel source and this test would then run instead of skipping. It is queued behind other work in the same area and is not posted yet; I hope to send it before long. Once the test actually runs somewhere, closing this will mean something.