| Message ID | 20251208091148.368769-1-changqing.li@windriver.com |
|---|---|
| State | Accepted, archived |
| Commit | 0642d2323072f561a4d0eeb9266213387b2997fc |
| Headers | show |
| Series | [1/2] go.bbclass: change GOTMPDIR to improve reproducibility | expand |
On Mon, 8 Dec 2025 at 10:11, Changqing Li via lists.openembedded.org <changqing.li=windriver.com@lists.openembedded.org> wrote: > This patch changes GOTMPDIR from ${WORKDIR}/build-tmp to > ${WORKDIR}/go-build-tmp so that the path no longer matches ${B}. This > prevents unintended replacements by OE's DEBUG_PREFIX_MAP and > restores reproducibility. Wait. Go does not have reproducibility problems right now: it is a part of reproducibility test, and not in the exclusion list. So how can the issues that this patch set aims to fix be observed? Alex
On 12/8/25 18:41, Alexander Kanavin 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 Mon, 8 Dec 2025 at 10:11, Changqing Li via lists.openembedded.org > <changqing.li=windriver.com@lists.openembedded.org> wrote: > >> This patch changes GOTMPDIR from ${WORKDIR}/build-tmp to >> ${WORKDIR}/go-build-tmp so that the path no longer matches ${B}. This >> prevents unintended replacements by OE's DEBUG_PREFIX_MAP and >> restores reproducibility. > Wait. Go does not have reproducibility problems right now: it is a > part of reproducibility test, and not in the exclusion list. So how > can the issues that this patch set aims to fix be observed? I checked autobuilder configs, although we have reproducible test, but only test with openembeded-core and layers under meta-openembeded, and there is no recipe inherit go.bbclass(except etcd under meta-oe, but already skipped) So actually, we don't have reproducible test for recipes that compile with go. And I tested with this step: on a host, with build path ra, and another build path rb-extend, bitbake buildah under both project, the rpm of ra, and rb-extend is different, and with these 2 patches, the rpm will be the same. //Changqing > > Alex
On Tue, 9 Dec 2025 at 03:37, Changqing Li <changqing.li@windriver.com> wrote: > Wait. Go does not have reproducibility problems right now: it is a > part of reproducibility test, and not in the exclusion list. So how > can the issues that this patch set aims to fix be observed? > > I checked autobuilder configs, although we have reproducible test, but only test with openembeded-core > > and layers under meta-openembeded, and there is no recipe inherit go.bbclass(except etcd under meta-oe, but already skipped) > > So actually, we don't have reproducible test for recipes that compile with go. I see. I was confused and thought this fixes the go toolchain somehow. There is one recipe on oe-core that does inherit go class (go-helloworld), can you check why reproducibility issues don't happen there? It would be good to have a reproducibility test for things written in go in core, so this doesn't again regress quietly. Alex
On 12/9/25 17:39, Alexander Kanavin 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 Tue, 9 Dec 2025 at 03:37, Changqing Li<changqing.li@windriver.com> wrote: >> Wait. Go does not have reproducibility problems right now: it is a >> part of reproducibility test, and not in the exclusion list. So how >> can the issues that this patch set aims to fix be observed? >> >> I checked autobuilder configs, although we have reproducible test, but only test with openembeded-core >> >> and layers under meta-openembeded, and there is no recipe inherit go.bbclass(except etcd under meta-oe, but already skipped) >> >> So actually, we don't have reproducible test for recipes that compile with go. > I see. I was confused and thought this fixes the go toolchain somehow. > > There is one recipe on oe-core that does inherit go class > (go-helloworld), can you check why reproducibility issues don't happen > there? It would be good to have a reproducibility test for things > written in go in core, so this doesn't again regress quietly. This issue reproduced when cgo is enabled, and go internally add --ffile-prefix-map="WorkDir"=/tmp/go-build" to gcc to tell gcc not include workdir in object file. for go-helloworld, it should be pure go, does not include the "C", so it will not met this issue. //Changqing > Alex
On Tue, 9 Dec 2025 at 11:13, Changqing Li <changqing.li@windriver.com> wrote: > This issue reproduced when cgo is enabled, and go internally add --ffile-prefix-map="WorkDir"=/tmp/go-build" to gcc > > to tell gcc not include workdir in object file. for go-helloworld, it should be pure go, does not include the "C", so it will not met this issue. Alright. The patches are ok then, please summarize these points in v2 commit messages. Alex
On Tue, 9 Dec 2025 at 11:13, Changqing Li <changqing.li@windriver.com> wrote: > There is one recipe on oe-core that does inherit go class > (go-helloworld), can you check why reproducibility issues don't happen > there? It would be good to have a reproducibility test for things > written in go in core, so this doesn't again regress quietly. > > This issue reproduced when cgo is enabled, and go internally add --ffile-prefix-map="WorkDir"=/tmp/go-build" to gcc > > to tell gcc not include workdir in object file. for go-helloworld, it should be pure go, does not include the "C", so it will not met this issue. I have filed a bugzilla ticket for the missong cgo reproducibility testing: https://bugzilla.yoctoproject.org/show_bug.cgi?id=16100 If you have ideas how to address it (with something minimal) in oe-core, that would be welcome. Alex
diff --git a/meta/classes-recipe/go.bbclass b/meta/classes-recipe/go.bbclass index e0f667373e..ed986ff5d4 100644 --- a/meta/classes-recipe/go.bbclass +++ b/meta/classes-recipe/go.bbclass @@ -79,7 +79,7 @@ B = "${WORKDIR}/build" export GOPATH = "${B}" export GOENV = "off" export GOPROXY ??= "https://proxy.golang.org,direct" -export GOTMPDIR ?= "${WORKDIR}/build-tmp" +export GOTMPDIR ?= "${WORKDIR}/go-build-tmp" GOTMPDIR[vardepvalue] = "" GO_SRCURI_DESTSUFFIX = "${@os.path.join(os.path.basename(d.getVar('S')), 'src', d.getVar('GO_IMPORT')) + '/'}"