Three hours in. I know much more about embedded GOROOT paths.

Interestingly, the compiler will patch the paths of the symbols in the stdlib to match the GOROOT. That's smart, avoids recompiling the stdlib at every GOROOT change, but allows debuggers to find the stdlib files.

Also, should make reproducible builds just work.

So it's not this.

But! Go binaries also get the *default* GOROOT copied in. The one that the compiler will use if no GOROOT is set, which was set at (compiler) compile time. Binaries need to know it to behave exactly like the compiler that built them.

So this is a fixed diff. But I don't see how it would affect the build ID.

Interesting read: https://github.com/golang/go/issues/17943

Figured it out! 🙌 And got it to reproduce 💥

The default GOROOT matters to the build ID because it's written to zversion.go, which is intentionally hashed in to detect toolchain changes.

Not, as I thought, because of the filepaths in the stdlib build IDs. The tree is recomputed with the current GOROOT instead. So every time you change GOROOT, the stdlib *is* rebuilt. (My previous tweet was wrong!)

All bets are off, it's Filippo is stupid.