public inbox for openembedded-core@lists.openembedded.org
 help / color / mirror / Atom feed
From: Changqing Li <changqing.li@windriver.com>
To: Richard Purdie <richard.purdie@linuxfoundation.org>,
	openembedded-core@lists.openembedded.org,
	bruce.ashfield@gmail.com, mathieu.dubois-briand@bootlin.com
Subject: Re: [OE-core] [PATCH V4] go.bbclass: set buildid to empty string to improve reproducibility
Date: Fri, 23 Jan 2026 18:35:22 +0800	[thread overview]
Message-ID: <703def79-e544-412c-bac1-4d30cf7ad65f@windriver.com> (raw)
In-Reply-To: <188AC968E243AEBC.2595076@lists.openembedded.org>

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


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]
> -=-=-=-=-=-=-=-=-=-=-=-
>

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

  parent reply	other threads:[~2026-01-23 10:35 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-01-14  6:44 [PATCH V4] go.bbclass: set buildid to empty string to improve reproducibility changqing.li
2026-01-14 12:36 ` Richard Purdie
2026-01-15  3:20   ` Changqing Li
     [not found]   ` <188AC968E243AEBC.2595076@lists.openembedded.org>
2026-01-23 10:35     ` Changqing Li [this message]
2026-01-23 21:10       ` [OE-core] " Randolph Sapp
2026-01-26  8:26         ` Changqing Li
     [not found] <188A85EB176781B4.2595076@lists.openembedded.org>
2026-01-14  6:48 ` Changqing Li

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=703def79-e544-412c-bac1-4d30cf7ad65f@windriver.com \
    --to=changqing.li@windriver.com \
    --cc=bruce.ashfield@gmail.com \
    --cc=mathieu.dubois-briand@bootlin.com \
    --cc=openembedded-core@lists.openembedded.org \
    --cc=richard.purdie@linuxfoundation.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox