[PATCH V4] go.bbclass: set buildid to empty string to improve reproducibility

[PATCH V4] go.bbclass: set buildid to empty string to improve reproducibility

[changqing.li]

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]

Refer:
[1] https://github.com/golang/go/blob/master/src/cmd/go/internal/work/buildid.go#L26
[2] https://github.com/golang/go/blob/master/src/cmd/go/internal/modindex/read.go#L70
[3] https://github.com/golang/go/issues/77086
[4] https://github.com/golang/go/issues/34186

Signed-off-by: Changqing Li <changqing.li@windriver.com>
---
 meta/classes-recipe/go.bbclass | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/meta/classes-recipe/go.bbclass b/meta/classes-recipe/go.bbclass
index b540471ba2..1c43b36fc0 100644
--- a/meta/classes-recipe/go.bbclass
+++ b/meta/classes-recipe/go.bbclass
@@ -51,11 +51,12 @@ GO_RPATH:class-native = "${@'-r ${STAGING_LIBDIR_NATIVE}/go/pkg/${TARGET_GOTUPLE
 GO_RPATH_LINK:class-native = "${@'-Wl,-rpath-link=${STAGING_LIBDIR_NATIVE}/go/pkg/${TARGET_GOTUPLE}_dynlink' if d.getVar('GO_DYNLINK') else ''}"
 GO_EXTLDFLAGS ?= "${HOST_CC_ARCH}${TOOLCHAIN_OPTIONS} ${GO_RPATH_LINK} ${LDFLAGS}"
 GO_LINKMODE ?= ""
+GO_BUILDID ?= "-buildid="
 GO_EXTRA_LDFLAGS ?= ""
 GO_LINUXLOADER ?= "-I ${@get_linuxloader(d)}"
 # Use system loader. If uninative is used, the uninative loader will be patched automatically
 GO_LINUXLOADER:class-native = ""
-GO_LDFLAGS ?= '-ldflags="${GO_RPATH} ${GO_LINKMODE} ${GO_LINUXLOADER} ${GO_EXTRA_LDFLAGS} -extldflags '${GO_EXTLDFLAGS}'"'
+GO_LDFLAGS ?= '-ldflags="${GO_RPATH} ${GO_LINKMODE} ${GO_LINUXLOADER} ${GO_EXTRA_LDFLAGS} ${GO_BUILDID} -extldflags '${GO_EXTLDFLAGS}'"'
 export GOBUILDFLAGS ?= "-v ${GO_LDFLAGS} -trimpath"
 export GOPATH_OMIT_IN_ACTIONID ?= "1"
 export GOPTESTBUILDFLAGS ?= "${GOBUILDFLAGS} -c"
-- 
2.34.1

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

[Changqing Li]

Hi, Richard, Mathieu

I noticed V2 of this patch is in master-next,   and this is just a kind 
reminder,

The only difference between V4 and V2 is the "commit message"

Regards

Changqing

On 1/14/26 14:44, Changqing Li via lists.openembedded.org 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]
>
> Refer:
> [1] https://github.com/golang/go/blob/master/src/cmd/go/internal/work/buildid.go#L26
> [2] https://github.com/golang/go/blob/master/src/cmd/go/internal/modindex/read.go#L70
> [3] https://github.com/golang/go/issues/77086
> [4] https://github.com/golang/go/issues/34186
>
> Signed-off-by: Changqing Li <changqing.li@windriver.com>
> ---
>   meta/classes-recipe/go.bbclass | 3 ++-
>   1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/meta/classes-recipe/go.bbclass b/meta/classes-recipe/go.bbclass
> index b540471ba2..1c43b36fc0 100644
> --- a/meta/classes-recipe/go.bbclass
> +++ b/meta/classes-recipe/go.bbclass
> @@ -51,11 +51,12 @@ GO_RPATH:class-native = "${@'-r ${STAGING_LIBDIR_NATIVE}/go/pkg/${TARGET_GOTUPLE
>   GO_RPATH_LINK:class-native = "${@'-Wl,-rpath-link=${STAGING_LIBDIR_NATIVE}/go/pkg/${TARGET_GOTUPLE}_dynlink' if d.getVar('GO_DYNLINK') else ''}"
>   GO_EXTLDFLAGS ?= "${HOST_CC_ARCH}${TOOLCHAIN_OPTIONS} ${GO_RPATH_LINK} ${LDFLAGS}"
>   GO_LINKMODE ?= ""
> +GO_BUILDID ?= "-buildid="
>   GO_EXTRA_LDFLAGS ?= ""
>   GO_LINUXLOADER ?= "-I ${@get_linuxloader(d)}"
>   # Use system loader. If uninative is used, the uninative loader will be patched automatically
>   GO_LINUXLOADER:class-native = ""
> -GO_LDFLAGS ?= '-ldflags="${GO_RPATH} ${GO_LINKMODE} ${GO_LINUXLOADER} ${GO_EXTRA_LDFLAGS} -extldflags '${GO_EXTLDFLAGS}'"'
> +GO_LDFLAGS ?= '-ldflags="${GO_RPATH} ${GO_LINKMODE} ${GO_LINUXLOADER} ${GO_EXTRA_LDFLAGS} ${GO_BUILDID} -extldflags '${GO_EXTLDFLAGS}'"'
>   export GOBUILDFLAGS ?= "-v ${GO_LDFLAGS} -trimpath"
>   export GOPATH_OMIT_IN_ACTIONID ?= "1"
>   export GOPTESTBUILDFLAGS ?= "${GOBUILDFLAGS} -c"
>
> -=-=-=-=-=-=-=-=-=-=-=-
> Links: You receive all messages sent to this group.
> View/Reply Online (#229303): https://lists.openembedded.org/g/openembedded-core/message/229303
> 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]
> -=-=-=-=-=-=-=-=-=-=-=-
>

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

[Richard Purdie]

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?

I'm very reticent to remove them entirely, that doesn't feel like a
good solution.

Cheers,

Richard

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

[Changqing Li]

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.
>
> Cheers,
>
> Richard

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

[Changqing Li]

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

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

[Randolph Sapp]

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. 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

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

[Changqing Li]

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