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
If the host machine does not have the GOROOT env. variable set (it's not a requirement to be set), then it uses values that are written to the binary file itself. Those values may be different if compiled on different host machines or if you use homebrew and upgrade the Go to a different version.
To test this theory I've written a small program that displays the build's default context.
I've built the same program on two different hosts with two different Go versions installed. One is the Linux machine (inside of a docker container) and the other one is my host machine which is the macOS 10.13.3.
I've built the from_linux binary inside of a Docker container for the macOS, then I run it from the macOS. I've also built the same binary on the host machine itself.
Running both binaries locally, it's visible that GOROOT is different.
The same thing happens when you are using homebrew to upgrade go. If you built the gopkgs on version Go version 1.11.11 and then upgrade Go to version 1.12.6, it will not list any of those Go related packages because the folder does not exist anymore. It was deleted by the homebrew. This is what happens to me every few months.
And of course, setting the GOROOT env variable fixes the problem:
The text was updated successfully, but these errors were encountered:
Every couple of months I notice that
gopkgs
stops listing Go's packages such as "time", "os", "net/http" and others.I think that I was able to pinpoint why that thing happens. Inside the codebase, there are usages of the
build.Default.GOROOT
(fromgo/build
package):gopkgs/x/tools/imports/fix.go
Line 516 in 29d3292
If the host machine does not have the GOROOT env. variable set (it's not a requirement to be set), then it uses values that are written to the binary file itself. Those values may be different if compiled on different host machines or if you use homebrew and upgrade the Go to a different version.
To test this theory I've written a small program that displays the build's default context.
I've built the same program on two different hosts with two different Go versions installed. One is the Linux machine (inside of a docker container) and the other one is my host machine which is the macOS 10.13.3.
I've built the
from_linux
binary inside of a Docker container for the macOS, then I run it from the macOS. I've also built the same binary on the host machine itself.Running both binaries locally, it's visible that GOROOT is different.
The same thing happens when you are using homebrew to upgrade go. If you built the
gopkgs
on version Go version1.11.11
and then upgrade Go to version1.12.6
, it will not list any of those Go related packages because the folder does not exist anymore. It was deleted by the homebrew. This is what happens to me every few months.And of course, setting the GOROOT env variable fixes the problem:
The text was updated successfully, but these errors were encountered: