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, changqing.li@windriver.com wrote:
>>> From: Changqing Li <changqing.li@windriver.com>
>>>
>>> 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
>
> -=-=-=-=-=-=-=-=-=-=-=-
> Links: You receive all messages sent to this group.
> View/Reply Online (#229382):https://lists.openembedded.org/g/openembedded-core/message/229382
> Mute This Topic:https://lists.openembedded.org/mt/117257536/3616873
> Group Owner:openembedded-core+owner@lists.openembedded.org
> Unsubscribe:https://lists.openembedded.org/g/openembedded-core/unsub [changqing.li@windriver.com]
> -=-=-=-=-=-=-=-=-=-=-=-
>