Join GitHub today
GitHub is home to over 36 million developers working together to host and review code, manage projects, and build software together.Sign up
proposal: runtime: provide a more usable alternative to GOROOT #22303
runtime.GOROOT in a pre-compiled binary is going to be wrong approximately 100% of the time.
AFAIK, there's currently no way for a go program to get the "real" GOROOT on a machine aside from running
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
It could be implemented similar to the current impl of findGOROOT used by the go tool:
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:
^^ Figuring out that this step is necessary is extremely difficult right now.
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.
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.
referenced this issue
Oct 24, 2017
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
I don't see any need for a new runtime function here.