From: Bruce Ashfield <[email protected]>
Integrating the following commit(s) to linux-yocto/7.2:
1/1 [
Author: Bruce Ashfield
Email: [email protected]
Subject: x86/Kconfig.cpu: pin CC_HAS_MARCH_NATIVE off for reproducible
builds
Date: Tue, 22 Sep 2026 14:26:03 -0400
CONFIG_CC_HAS_MARCH_NATIVE is a def_bool computed from
$(cc-option, -march=native), i.e. it is probed from the build-host
compiler. In cross builds the result varies by build host: the kernel's
own comment already notes "This flag might not be available in
cross-compilers" So it is captured differently across otherwise
identical builds and breaks kernel package reproducibility:
.config / auto.conf: CONFIG_CC_HAS_MARCH_NATIVE=y (host A) vs absent
(host B)
autoconf.h: #define CONFIG_CC_HAS_MARCH_NATIVE 1
.config: # CONFIG_X86_NATIVE_CPU is not set
rustc_cfg: --cfg=CONFIG_CC_HAS_MARCH_NATIVE
With CONFIG_IKCONFIG=y the .config is gzip-embedded into the kernel
(kernel_config_data), so the difference also propagates into
vmlinux/bzImage/kernel-dbg (the blob shifts kernel_config_data_end and
every symbol after it), failing reproducibility across the whole kernel
package set. Not just the config text files, which is why a post-package
filter is not sufficient.
CC_HAS_MARCH_NATIVE protects only X86_NATIVE_CPU ("build and optimize
for local/native CPU"), which is never enabled in these builds and
is not something we should do in a distributed/reproducible
kernel. Pin the symbol off so the captured config is deterministic
regardless of build host. On-target 'make scripts prepare' uses
this same patched Kconfig, so it recomputes the same value and
needs no reconfiguration.
Signed-off-by: Bruce Ashfield <[email protected]>
]
Signed-off-by: Bruce Ashfield <[email protected]>
---
This and the 6.18 fix are the same. You can see the details in the
commit message I captured above.
There's no generic/general solution at the moment, since we can't
drop the problematic values from the .config without changing
timestamps and then having the kernel just regenerate the configs.
We could probably dance around the timestamps for a bit and we'd
fix half the problem, but the .config compiled into the binary would
mean we'd also have to do the timestap fixes all through the build
and it has proven fragile in the past.
I checked this by grepping for the symbols between different builds
and they looked good.
The true test is the AB, so hopefully it holds there as well.
Bruce
.../linux/linux-yocto-rt_7.2.bb | 4 ++--
.../linux/linux-yocto-tiny_7.2.bb | 4 ++--
meta/recipes-kernel/linux/linux-yocto_7.2.bb | 20 +++++++++----------
3 files changed, 14 insertions(+), 14 deletions(-)
diff --git a/meta/recipes-kernel/linux/linux-yocto-rt_7.2.bb
b/meta/recipes-kernel/linux/linux-yocto-rt_7.2.bb
index 438c896749..e8e6c885ca 100644
--- a/meta/recipes-kernel/linux/linux-yocto-rt_7.2.bb
+++ b/meta/recipes-kernel/linux/linux-yocto-rt_7.2.bb
@@ -15,8 +15,8 @@ python () {
raise bb.parse.SkipRecipe("Set PREFERRED_PROVIDER_virtual/kernel to
linux-yocto-rt to enable it")
}
-SRCREV_machine ?= "c2f967f4c1065d41084f300d3eca7cd413635dc3"
-SRCREV_meta ?= "b5d69636e3e56aa6a5b8f987b4587e7a56c4782a"
+SRCREV_machine ?= "c3c2a26425ad13ed7d2bee0ff6f11365564bb33d"
+SRCREV_meta ?= "242eecdf2cb368016f92ad5317702b20f71d8c1e"
SRC_URI =
"git://git.yoctoproject.org/linux-yocto.git;branch=${KBRANCH};name=machine;protocol=https
\
git://git.yoctoproject.org/yocto-kernel-cache;type=kmeta;name=meta;branch=yocto-7.2;destsuffix=${KMETA};protocol=https"
diff --git a/meta/recipes-kernel/linux/linux-yocto-tiny_7.2.bb
b/meta/recipes-kernel/linux/linux-yocto-tiny_7.2.bb
index 0a9595a749..fe2666b86d 100644
--- a/meta/recipes-kernel/linux/linux-yocto-tiny_7.2.bb
+++ b/meta/recipes-kernel/linux/linux-yocto-tiny_7.2.bb
@@ -18,8 +18,8 @@ DEPENDS += "openssl-native util-linux-native"
KMETA = "kernel-meta"
KCONF_BSP_AUDIT_LEVEL = "2"
-SRCREV_machine ?= "d8a1ec518ab72fadb60dbe9eed3775b68975defd"
-SRCREV_meta ?= "b5d69636e3e56aa6a5b8f987b4587e7a56c4782a"
+SRCREV_machine ?= "2ebaf2d45071d568d23e6570811bd63fb7cde633"
+SRCREV_meta ?= "242eecdf2cb368016f92ad5317702b20f71d8c1e"
PV = "${LINUX_VERSION}+git"
diff --git a/meta/recipes-kernel/linux/linux-yocto_7.2.bb
b/meta/recipes-kernel/linux/linux-yocto_7.2.bb
index f1c2d475c1..55326a647b 100644
--- a/meta/recipes-kernel/linux/linux-yocto_7.2.bb
+++ b/meta/recipes-kernel/linux/linux-yocto_7.2.bb
@@ -17,18 +17,18 @@ KBRANCH:qemux86-64 ?= "v7.2/standard/base"
KBRANCH:qemuloongarch64 ?= "v7.2/standard/base"
KBRANCH:qemumips64 ?= "v7.2/standard/mti-malta"
-SRCREV_machine:qemuarm ?= "56c7106647e505ca1fb15fd433b0bc991024764c"
-SRCREV_machine:qemuarm64 ?= "d8a1ec518ab72fadb60dbe9eed3775b68975defd"
-SRCREV_machine:qemuloongarch64 ?= "d8a1ec518ab72fadb60dbe9eed3775b68975defd"
+SRCREV_machine:qemuarm ?= "3b075480e3eb36dbdbb7459ceb8220e30c168f7f"
+SRCREV_machine:qemuarm64 ?= "2ebaf2d45071d568d23e6570811bd63fb7cde633"
+SRCREV_machine:qemuloongarch64 ?= "2ebaf2d45071d568d23e6570811bd63fb7cde633"
SRCREV_machine:qemumips ?= "ab0e33fefa2a3d0366b2b8deb7cfb3be2d8dc436"
-SRCREV_machine:qemuppc ?= "d8a1ec518ab72fadb60dbe9eed3775b68975defd"
-SRCREV_machine:qemuriscv64 ?= "d8a1ec518ab72fadb60dbe9eed3775b68975defd"
-SRCREV_machine:qemuriscv32 ?= "d8a1ec518ab72fadb60dbe9eed3775b68975defd"
-SRCREV_machine:qemux86 ?= "d8a1ec518ab72fadb60dbe9eed3775b68975defd"
-SRCREV_machine:qemux86-64 ?= "d8a1ec518ab72fadb60dbe9eed3775b68975defd"
+SRCREV_machine:qemuppc ?= "2ebaf2d45071d568d23e6570811bd63fb7cde633"
+SRCREV_machine:qemuriscv64 ?= "2ebaf2d45071d568d23e6570811bd63fb7cde633"
+SRCREV_machine:qemuriscv32 ?= "2ebaf2d45071d568d23e6570811bd63fb7cde633"
+SRCREV_machine:qemux86 ?= "2ebaf2d45071d568d23e6570811bd63fb7cde633"
+SRCREV_machine:qemux86-64 ?= "2ebaf2d45071d568d23e6570811bd63fb7cde633"
SRCREV_machine:qemumips64 ?= "ab0e33fefa2a3d0366b2b8deb7cfb3be2d8dc436"
-SRCREV_machine ?= "d8a1ec518ab72fadb60dbe9eed3775b68975defd"
-SRCREV_meta ?= "b5d69636e3e56aa6a5b8f987b4587e7a56c4782a"
+SRCREV_machine ?= "2ebaf2d45071d568d23e6570811bd63fb7cde633"
+SRCREV_meta ?= "242eecdf2cb368016f92ad5317702b20f71d8c1e"
# set your preferred provider of linux-yocto to 'linux-yocto-upstream', and
you'll
# get the <version>/base branch, which is pure upstream -stable, and the same
--
2.43.0
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#246433):
https://lists.openembedded.org/g/openembedded-core/message/246433
Mute This Topic: https://lists.openembedded.org/mt/121387751/21656
Group Owner: [email protected]
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[[email protected]]
-=-=-=-=-=-=-=-=-=-=-=-
