Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

proposal: runtime: provide a more usable alternative to GOROOT #22303

Closed
natefinch opened this issue Oct 17, 2017 · 6 comments

Comments

Projects
None yet
3 participants
@natefinch
Copy link
Contributor

commented Oct 17, 2017

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:

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:

BuildContext.GOROOT = GOROOT

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

@gopherbot gopherbot added this to the Proposal milestone Oct 17, 2017

@gopherbot gopherbot added the Proposal label Oct 17, 2017

@ianlancetaylor ianlancetaylor changed the title Proposal: Provide a more usable alternative to runtime.GOROOT proposal: runtime: provide a more usable alternative to GOROOT Oct 17, 2017

@ianlancetaylor

This comment has been minimized.

Copy link
Contributor

commented Oct 17, 2017

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

This comment has been minimized.

Copy link
Contributor Author

commented Oct 17, 2017

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

This comment has been minimized.

Copy link
Contributor

commented Oct 17, 2017

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

This comment has been minimized.

Copy link
Contributor

commented Oct 17, 2017

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

@natefinch

This comment has been minimized.

Copy link
Contributor Author

commented Oct 17, 2017

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

This comment has been minimized.

Copy link
Contributor

commented Mar 19, 2018

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.

@golang golang locked and limited conversation to collaborators Mar 19, 2019

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
You can’t perform that action at this time.