$ go version
go version devel +a3bc52b786 Wed Oct 14 13:38:41 2020 +0000 linux/amd64
Does this issue reproduce with the latest release?
On tip, yes.
What operating system and processor architecture are you using (go env)?
go env Output
$ go env
GOGCCFLAGS="-fPIC -m64 -pthread -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build221597016=/tmp/go-build -gno-record-gcc-switches"
GOROOT/bin/go version: go version devel +a3bc52b786 Wed Oct 14 13:38:41 2020 +0000 linux/amd64
GOROOT/bin/go tool compile -V: compile version devel +a3bc52b786 Wed Oct 14 13:38:41 2020 +0000
uname -sr: Linux 5.8.14-zen1-1-zen
/usr/lib/libc.so.6: GNU C Library (GNU libc) release release version 2.32.
gdb --version: GNU gdb (GDB) 9.2
What did you do?
I was trying out the new GODEBUG=inittrace=1 support, so I ran GODEBUG=inittrace=1 gotip build. This was probably a mistake; I really just wanted to test it on the output binary. No problem, I just ran the resulting binary with the option instead and saw the output I wanted.
Later, I ran gotip build again.
What did you expect to see?
A blank output.
What did you see instead?
I was surprised to see that the init tracing was still enabled, even though I didn't have GODEBUG set in my environment. The packages being listed were the packages I had previously built.
It seems like this option might be missing from a cache hash somewhere. Clearing the build cache (or updating gotip) fixes the issue. But, I've read the CL, and it doesn't seem to modify the compiler in any way, so I have no idea what's going on.
I ran the commands from above starting with a clean 'go get golang.org/dl/gotip' and then 'gotip download' and then the sequence of above commands posted and I can not reproduce the problem on a toy hello world program on darwin.
Not sure how complex the program is gotip build is compiling but can you reproduce this with a toy hello world program? It might be that some more sophisticated part of the toolchain somehow includes standard error into some build artifact. Maybe its just the linker as cherrymui points out. Not sure how we can check its the same issue and fixing #27628 will also fix your specific case.
All of the packages printed in the second gotip build are for non-stdlib dependencies. If you import something external, it appears to matter. My guess is that the stdlib has already been compiled by the bootstrap process, though that'd seem like it'd negatively affect the trace (if it was skipped for already-built packages), so that's probably not fully true.
Try this reproducer: