You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The original report was that if you unpack a distribution expecting to go into /usr/local/go into, say, /tmp/go, and then you build a binary, the result of runtime.GOROOT() from that binary says /usr/local/go instead of /tmp/go (unless you've explicitly set $GOROOT to /tmp/go or something else). The reporter wanted to get /tmp/go instead.
CL 61310 added this logic:
if cfg.GOROOT != runtime.GOROOT() {
ldflags = append(ldflags, "-X=runtime/internal/sys.DefaultGoroot="+cfg.GOROOT)
}
cfg.GOROOT is the GOROOT deduced from the location of the go command (so in this case /tmp/go/bin/go yields /tmp/go), and assuming $GOROOT isn't set runtime.GOROOT() still returns /usr/local/go, so the condition is true, and the -X flag overrides the setting of sys.DefaultGoroot.
But this is probably not right, for at least two reasons.
First, if you do have $GOROOT set to /tmp/go, because you think you need to do that to make anything work properly (as you did before cmd/go sniffed out GOROOT as well as it does today), then runtime.GOROOT() will return /tmp/go, the -X will not be added, and and the resulting binary will have a DefaultGoroot of /usr/local/go, just like before the change.
Second, it doesn't seem to be stable. If you run /tmp/go install -a std cmd, hoping to improve the situation, that actually does install a new /tmp/go/bin/go with DefaultGoroot=/tmp/go due to the -X flag, but the original runtime source code has not changed. Then if you run a build with the newly installed /tmp/go/bin/go, it will think it's in the right place, because inside that binary DefaultGoroot=/tmp/go, even though in the runtime sources it is not. So all the binaries /tmp/go builds at that point will not use the -X flag and will end up with the /usr/local/go default. If you run /tmp/go install -a std cmd again you'll get a toolchain with /usr/local/go. It will flip back and forth.
I might be wrong - I haven't tried this - but assuming I am right these both seem problematic to me.
I understand the motivation but I think the fix is probably something different. Filing this bug so we don't forget, and I'll return to this once other cmd/go work is done.
CL 61310 fixed #21313.
The original report was that if you unpack a distribution expecting to go into /usr/local/go into, say, /tmp/go, and then you build a binary, the result of
runtime.GOROOT()
from that binary says/usr/local/go
instead of/tmp/go
(unless you've explicitly set $GOROOT to /tmp/go or something else). The reporter wanted to get/tmp/go
instead.CL 61310 added this logic:
cfg.GOROOT is the GOROOT deduced from the location of the go command (so in this case /tmp/go/bin/go yields /tmp/go), and assuming $GOROOT isn't set runtime.GOROOT() still returns /usr/local/go, so the condition is true, and the -X flag overrides the setting of sys.DefaultGoroot.
But this is probably not right, for at least two reasons.
First, if you do have $GOROOT set to /tmp/go, because you think you need to do that to make anything work properly (as you did before cmd/go sniffed out GOROOT as well as it does today), then runtime.GOROOT() will return /tmp/go, the -X will not be added, and and the resulting binary will have a DefaultGoroot of /usr/local/go, just like before the change.
Second, it doesn't seem to be stable. If you run
/tmp/go install -a std cmd
, hoping to improve the situation, that actually does install a new /tmp/go/bin/go with DefaultGoroot=/tmp/go due to the -X flag, but the original runtime source code has not changed. Then if you run a build with the newly installed /tmp/go/bin/go, it will think it's in the right place, because inside that binary DefaultGoroot=/tmp/go, even though in the runtime sources it is not. So all the binaries /tmp/go builds at that point will not use the -X flag and will end up with the /usr/local/go default. If you run/tmp/go install -a std cmd
again you'll get a toolchain with /usr/local/go. It will flip back and forth.I might be wrong - I haven't tried this - but assuming I am right these both seem problematic to me.
I understand the motivation but I think the fix is probably something different. Filing this bug so we don't forget, and I'll return to this once other cmd/go work is done.
/cc @crawshaw
The text was updated successfully, but these errors were encountered: