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. 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 - Randolph
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#229915): https://lists.openembedded.org/g/openembedded-core/message/229915 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]] -=-=-=-=-=-=-=-=-=-=-=-
