Re: [OE-core] [PATCH V4] go.bbclass: set buildid to empty string to improve reproducibility

[Changqing Li <changqing.li@windriver.com>]

[-- Attachment #1: Type: text/plain, Size: 5803 bytes --]


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,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
>>>
>>>
> 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 (#229915):https://lists.openembedded.org/g/openembedded-core/message/229915
> 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]
> -=-=-=-=-=-=-=-=-=-=-=-
>

[-- Attachment #2: Type: text/html, Size: 8313 bytes --]