Comment 1:

I don't see how this would work. If you've moved your Go install from the place you've
compiled it to somewhere else then you need to override the value of $GOROOT embedded
into the go tool to make things work.
The better tool for this is to use GOROOT_FINAL when compiling Go.
It's hard to get excited about this, the path prefix of the code is much less
interesting than the other contents of the panic message.

Comment 2:

if we check out the source code from the same Repository, use the same version.
we expect the `go build` ouput is same.
but the `go build` ouput depends on $GOROOT and $GOPATH absolute path.

Comment 3:

if we check out the source code from the same Repository, use the same version.
we expect the `go build` output is same.
but the `go build` output depends on $GOROOT and $GOPATH absolute path.

Comment 4:

Maybe this is a request for bit-identical builds? issue #5170

Comment 5:

Full paths are intentional: a full path can be interpreted by other tools in ways that
relative paths or pseudo-paths cannot. You can change the eventual path with
$GOROOT_FINAL if that's the problem.

Status changed to WorkingAsIntended.