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.
@kennwhite Of course 😊 ❤
FYI, your fav might have gotten lost in the 500 our instance is suffering right now, because it doesn't show up on my side.
Server run by the main developers of the project It is not focused on any particular niche interest - everyone is welcome as long as you follow our code of conduct!