| Message ID | 20260114064400.4070617-1-changqing.li@windriver.com |
|---|---|
| State | New |
| Headers | show |
| Series | [V4] go.bbclass: set buildid to empty string to improve reproducibility | expand |
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
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
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] > -=-=-=-=-=-=-=-=-=-=-=- >
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
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] > -=-=-=-=-=-=-=-=-=-=-=- >
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"