On 1/24/26 05:10, Randolph Sapp via lists.openembedded.org wrote:
CAUTION: This email comes from a non Wind River email account!
Do not click links or open attachments unless you recognize the sender and know
the content is safe.
On Fri Jan 23, 2026 at 4:35 AM CST, Changqing Li via lists.openembedded.org
wrote:
On 1/15/26 11:20, Changqing Li via lists.openembedded.org wrote:
On 1/14/26 20:36, Richard Purdie wrote:
CAUTION: This email comes from a non Wind River email account!
Do not click links or open attachments unless you recognize the
sender and know the content is safe.
On Wed, 2026-01-14 at 14:44 +0800,[email protected] wrote:
From: Changqing Li<[email protected]>
Go packages and binaries are stamped with build IDs that record both
the
action ID, which is a hash of the inputs to the action that produced
the
packages or binary, and the content ID, which is a hash of the action
output, namely the archive or binary itself, Refer [1].
And action ID include hash of modroot, which will include build path,
so this make go package not reproducible.
Refer [2], keying off module path instead of module root directory
is a TODO.
[snip of log]
HASH[moduleIndex]: "go1.25.3"
HASH[moduleIndex]: "modroot
/build-a/tmp/work/x86-64-v3-wrs-linux/buildah/1.41.5/recipe-sysroot-native/usr/lib/go/src/cmd\n"
HASH[moduleIndex]: "package go1.25.3 go index v2
/build-a/tmp/work/x86-64-v3-wrs-linux/buildah/1.41.5/recipe-sysroot-native/usr/lib/go/src/cmd/buildid\n"
HASH[moduleIndex]: "file buildid.go 2025-10-13 16:08:43 +0000 UTC
1704\n"
HASH[moduleIndex]: "file doc.go 2025-10-13 16:08:43 +0000 UTC 558\n"
HASH[moduleIndex]:
007b9fe2edd5b3232f5c98ae6c46e80a435141cb627ba5418c5314c0cbf4df7b
Report this issue to upstream, refer [3]
Workaround the reproducible by setting buildid to empty, refer [4]
The trouble is there is a lot of potentially important information
going into these buildids and you're just removing that functionality
entirely.
Can we patch out the problematic component until it is fixed instead?
OK. I will check if it can be patched out.
//changqing
I'm very reticent to remove them entirely, that doesn't feel like a
good solution.
After do more investigation, it turns out that the not reproducible is
not caused by what the previous commit messsage mentioned modroot.
The root cause related to the cgo_ldflags, which may include build path.
Take buildah as example, it deps runtime/cgo, and runtime/cgo is
compiled into ar archive file _pkg_.a, and it includes _go_.o,
__.PKGDEF and other files.
_go_.o maybe include metadata "cgo_ldflags,
-ffile-prefix-map=buidpath/xxx=xxx", and meantime, _go_.o, __.PKGDEF all
embeded go buildid in them.
build buildah, deps on package runtime/cgo, so "import runtime/cgo
'contentID of this package'" will be part of actionID of buildah.
'content ID of this package' is the content ID of _pkg_.a. we cannot
change this content ID by simply exclude them like
what this line has done:
https://github.com/golang/go/blob/master/src/cmd/internal/buildid/rewrite.go#L46
because the build process will use this content hash, sometime verify
cached can be reused or do cache verify.
it is related to how go design like.
I have update this analyze result into:
https://github.com/golang/go/issues/77086.
And seems fix the reproducible issue by passing -buildid= is a safe way.
It only influences the last step when generating elf, the previous build
process still use the original actionID and contendID,
if we set buildid by pass -buildid=, it will influence what value will
be set into section ".note.go.buildid" in doelf.
Bruce had suggested to set buildid to a proper value like SRCREV. if
you all agree with this solution, I can try to send a V5 patch,
if I can get SRCREV, set -buildid=SRCREV, otherwise, still set buildid
empty? like:
GO_BUILDID ?= ' -buildid="${@d.getVar('SRCREV') if d.getVar('SRCREV') !=
'INVALID' else ( d.getVar('SRCREV_%s'%${PN}) if d.getVar('SRCREV_%s'%${PN}) != ''
else ( d.getVarFlag('SRC_URI', 'sha256sum') if d.getvarflag('sha256sum') != '' if ()
else ''
Regards
Changqing
Cheers,
Richard
Oh cool, someone else found the same issue I did.
+1
I submitted the following
patch the other day, since the only LDFLAG parameter that is actually breaking
build ID functionality is the prefix maps, which include build paths. That was a
change made way back when to address an issue that has long since been solved.
We can safely revert it now, assuming nobody is using external toolchains older
than GCC 12.
Alternatively, we could just conditionally remove those arguments for go
applications only. Up to you all.
https://lists.openembedded.org/g/openembedded-core/message/229857
I read this patch today, and I am wondering if we can remove the
DEBUG_PREFIX_MAP,
I replied in the patch mail loop, could you help to check if my
understanding is right?
//Changqing
- Randolph
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#229973):
https://lists.openembedded.org/g/openembedded-core/message/229973
Mute This Topic: https://lists.openembedded.org/mt/117257536/21656
Group Owner: [email protected]
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[[email protected]]
-=-=-=-=-=-=-=-=-=-=-=-
