This is odd because inittrace is purely a runtime thing it should not effect the build process. Can you reproduce the behaviour with 'gctrace' too?

What might happen is that stdout somehow gets mixed into some permanent build output but that would be a general problem.

I guess it caches the inittrace of the compiler/assembler/linker.

#27628 should address this.

Yep, same thing happens with gctrace. Repeating my steps again:

$ gotip clean -cache

$ GODEBUG=gctrace=1 gotip build
# lots of trace output

$ gotip build
# trace output for the packages in my project (and deps, though no stdlib?)

So this isn't just restricted to the new inittrace.

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:

package main

import (
	"fmt"

	"rsc.io/quote/v3"
)

func main() {
	fmt.Println(quote.GoV3())
}

Running my steps above, the last gotip build gives me: https://gist.github.com/zikaeroh/ef7c689bc36798fee9e5ca112b6b126b

ack. can reproduce this way.

Duplicate of #27628.