cmd/link: -B gobuildid doesn't work when building the toolchain itself

znkr commented 1 year ago

This is a follow up to #41004 which added support for -B gobuildid to cmd/link. Unfortunately, this doesn't work when building the toolchain itself.

What version of Go are you using (`go version`)?

tip

What did you do?

 % GO_LDFLAGS="-B gobuildid" ./make.bash

What did you expect to see?

A successful build producing Go toolchain binaries that have .note.gnu.build-id ELF section.

What did you see instead?

 % GO_LDFLAGS="-B gobuildid" ./make.bash
Building Go cmd/dist using /usr/lib/google-golang. (go1.22-20230729-RC00 cl/552016856 +457721cd52 X:fieldtrack,bo
ringcrypto linux/amd64)
Building Go toolchain1 using /usr/lib/google-golang.
Building Go bootstrap cmd/go (go_bootstrap) using Go toolchain1.
Building Go toolchain2 using go_bootstrap and Go toolchain1.
Building Go toolchain3 using go_bootstrap and Go toolchain2.
Building packages and commands for linux/amd64.
HASH[moduleIndex]
HASH[moduleIndex]: "devel go1.22-eca5a97340 Tue Sep 19 05:51:26 2023 +0000"
HASH[moduleIndex]: "modroot [RECACTED]/dev/go/src/cmd\n"
...
HASH[moduleIndex]: "file template.go 2023-09-19 12:37:51.569044164 +0000 UTC 7335\n"
HASH[moduleIndex]: 5cf632a5d0cc7bcf669b75b3abc54664c46ea44ca853a3d5812f5efccf086406
cmd/link true
go tool dist: unexpected stale targets reported by  [RECACTED]/dev/go/pkg/tool/linux_amd64/go_bootstrap list -gcflags="" -ldflags="-B gobuildid" for [cmd/asm cmd/cgo cmd/compile cmd/link] (consider rerunning with GOMAXPROCS=1 GODEBUG=gocachehash=1):
        STALE cmd/asm: stale dependency: internal/goarch
        STALE cmd/cgo: stale dependency: internal/goarch
        STALE cmd/compile: stale dependency: internal/goarch
        STALE cmd/link: stale dependency: internal/goarch

cherrymui commented 1 year ago

This is known, and we went back and forth a few times in CL https://go.dev/cl/511475 , and that is partly the reason we don't always do this (if -B is not otherwise set).

The issue is that the GNU build ID, being part of the toolchain binary, is considered as input for the next compilation. So there is a convergence problem. There are probably ways to solve it, and we've discussed a lot on the CL. But it needs more thoughts.

If you really want it, maybe you can do go install -ldflags=-B=gobuildid cmd/... after make.bash. That will make the standard library packages become stale and will need rebuild at the next compilation, but that is probably okay.

znkr commented 8 months ago

Thanks Cherry. I gave that a spin, but ran into new issues after trying that and gave up. In the end, I solved it by specifying a fixed build id that's overridden with the hash sum of the binary in a separate step after make.bash.

gopherbot commented 1 month ago

Change https://go.dev/cl/618597 mentions this issue: cmd/internal/buildid: skip over Mach-O UUID from buildid computation

gopherbot commented 1 month ago

Change https://go.dev/cl/618600 mentions this issue: cmd/internal/buildid: skip over GNU build ID from buildid computation

gopherbot commented 1 month ago

Change https://go.dev/cl/618601 mentions this issue: cmd/link: on ELF, generate GNU build ID by default

gopherbot commented 2 weeks ago

Change https://go.dev/cl/621639 mentions this issue: cmd/link: don't pass --build-id to C linker on Solaris

golang / go