proposal: runtime: provide a more usable alternative to GOROOT

[natefinch]

runtime.GOROOT in a pre-compiled binary is going to be wrong approximately 100% of the time.
It is documented as-such (though not so blatantly), but that doesn't excuse it. Its proximity to runtime.GOOS and runtime.GOARCH, which are correct basically 100% of the time in a running program make it even more deceiving.

AFAIK, there's currently no way for a go program to get the "real" GOROOT on a machine aside from running go env GOROOT... at least no way without copying code out of the implementation of go env.

I understand that many environments where an application runs may have no valid GOROOT. That would be useful information to have, too. Instead, runtime.GOROOT() makes every machine appear to have a GOROOT, even though it's almost always lying.

I propose adding a new function to runtime, spelled something like runtime.CurrentGOROOT() that returns either the real GOROOT if one exists on the current machine, or an empty string if we cannot determine the goroot.

It could be implemented similar to the current impl of findGOROOT used by the go tool:

go/src/cmd/go/internal/cfg/cfg.go

Line 99 in 1850874

func findGOROOT() string {

except using LookPath("go"). I know that this is far from guaranteed to work . in all situations, but at least it wouldn't be wrong nearly 100% of the time.

It's probably impossible to fix now, but it would be nice if go/build.Default used this, to avoid the very bizarre problem where a locally compiled binary works fine using build.Default, but the exact same code compiled on someone else's machine falls over with errors about the other machine's GOROOT.

Note that the go tool itself has to avoid this issue by overwriting the GOROOT on build.Default:

go/src/cmd/go/internal/cfg/cfg.go

Line 91 in 1850874

BuildContext.GOROOT = GOROOT

^^ Figuring out that this step is necessary is extremely difficult right now.

[ianlancetaylor]

What are the cases where an ordinary program needs to know the GOROOT value? I think we need to understand the uses before deciding whether the proposed solution makes sense.

[natefinch]

Define ordinary program? Anything that wants to parse go code using go/build, such as all the various linters, code generators, etc.

And for the record, I'm not at all married to the implementation, just used it as one possible solution. I'd be happy if someone has a better option for getting the "real" GOROOT.

[ianlancetaylor]

A program that is using the go/build package doesn't need to itself know GOROOT. It just needs the go/build package to know it. We could in principle fix go/build without adding new API to the runtime package.

[ianlancetaylor]

Also I feel I should add that gccgo, for example, has no equivalent to the gc toolchain's GOROOT.

[natefinch]

that's a fair characterization. I don't actually care about goroot. I just want the various parsers and importers to work in precompiled binaries. although since various things take a GOROOT field, it would be nice to be able to give them a valid value.

[ianlancetaylor]

If packages like go/build, or linters, code generators, etc., do not work correctly after the tools are installed, please file bugs against them.

If you want the actual runtime GOROOT value, it should work to call go env GOROOT.

I don't see any need for a new runtime function here.