cmd/go: go build -i results in "/usr/local/go/pkg/darwin_amd64/runtime/cgo.a: permission denied"

[xiaoxfan]

What version of Go are you using (go version)?

$ go version
go version go1.14 darwin/amd64

Does this issue reproduce with the latest release?

What operating system and processor architecture are you using (go env)?

go env Output

$ go env
GO111MODULE=""
GOARCH="amd64"
GOBIN=""
GOCACHE="/Users/hrbc/Library/Caches/go-build"
GOENV="/Users/hrbc/Library/Application Support/go/env"
GOEXE=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="darwin"
GOINSECURE=""
GONOPROXY=""
GONOSUMDB=""
GOOS="darwin"
GOPATH="/Users/hrbc/go"
GOPRIVATE=""
GOPROXY="https://proxy.golang.org,direct"
GOROOT="/usr/local/go"
GOSUMDB="sum.golang.org"
GOTMPDIR=""
GOTOOLDIR="/usr/local/go/pkg/tool/darwin_amd64"
GCCGO="gccgo"
AR="ar"
CC="clang"
CXX="clang++"
CGO_ENABLED="1"
GOMOD=""
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"
PKG_CONFIG="pkg-config"
GOGCCFLAGS="-fPIC -m64 -pthread -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -fdebug-prefix-map=/var/folders/7n/bh7jk7s95_3gljs6gf3405k00000gn/T/go-build782113827=/tmp/go-build -gno-record-gcc-switches -fno-common"

What did you do?

build my project use -i
go build -i -v -o ./bin/demo-api .

What did you expect to see?

no error

What did you see instead?

go build -i -v -o ./bin/demo-api .
go build runtime/cgo: copying /Users/hrbc/Library/Caches/go-build/63/63a132c80210b5c7b4f4ed9a902aaec712c42b15e23aa2c1b1778e2f85165d04-d: open /usr/local/go/pkg/darwin_amd64/runtime/cgo.a: permission denied

[bcmills]

This probably means that your go installation is read-only and/or owned by root instead of your user.

The -i flag is not particularly useful now that the go command has a build cache. Is there some particular reason you need it?

[ghost]

I had the same error when I installed golang using the .pkg file. Oddly(?), it only offered to install system-wide (i.e. for all users) and all the files installed to /usr/local/go were owned by root.

Removing golang (sudo rm -fr /usr/local/go), downloading and expanding the latest tar file helped:

sudo tar -C /usr/local -xzf go1.14.1.darwin-amd64.tar.gz

I no longer have that fakakta error. If it matters, I'm on macOS Mojave 10.14.6.

[jayconrod]

To clarify, the -i flag tells the go command to install any rebuilt packages to their canonical locations. For runtime/cgo, that would be $GOROOT/pkg/darwin_amd64/runtime/cgo.a, which may be read-only, depending on how Go was installed.

Since Go 1.10, which introduced the build cache, the -i flag should rarely be needed. runtime/cgo.a will be stored there with a name like ~/Library/Caches/go-build/63/63a132c80210b5c7b4f4ed9a902aaec712c42b15e23aa2c1b1778e2f85165d04-d.

@xiaoxfan @ppinter1 Could you say more about what you're using -i for? If the intent is just to speed up future builds by caching compiled packages, it's no longer needed.

[ghost]

In my case, I sometimes use the CLI, but mostly build projects using VScode with go extensions.

The VScode setting go.installDependenciesWhenBuilding defaults to true and adds the -i switch on building, but I believe that's a red herring and the underlying problem is that the go1.14.1.darwin-amd64.pkg file is hosed. If used, go gets installed with 'root' ownership.

However, using sudo to expand the go1.14.1.darwin-amd64.tar.gz file to /usr/local works.

[jayconrod]

@ppinter1 Thanks for clarifying. I remember changing the default was discussed in microsoft/vscode-go#2836. Maybe comment on that issue or open a new one?

It's expected that go1.14.1.darwin-amd64.pkg installs Go with root ownership. Any system-wide package installation should work that way. Personally, I use the .tar.gz files, but I have a script that chowns them to root so I don't accidentally mess up my installation later (I have in the past).

[ghost]

Ah, okay. Thanks for clearing that up. It's a good day when I learn summit and today's a good day.

[gopherbot]

Timed out in state WaitingForInfo. Closing.

(I am just a bot, though. Please speak up if this is a mistake or you have the requested information.)

[dhazeghi]

Atom and go-plus have exactly the same problem.

[JacobAndrewSmith92]

In the event anyone else is still seeing this problem with Go 1.14. I use Homebrew as my package manager but when I was installing go, I downloaded and installed it from the golang website.
I had to:
sudo rm -rf /usr/local/go

and install it via Homebrew:
brew install go

That resolved my issue.

[bitxel]

Another workaround:

sudo chown -R <your username> /usr/local/go/pkg/darwin_amd64/

[andreagrandi]

I installed Go 1.15 through the official installer and this still happens. Couldn't the installer provide a fix for this? Thanks

[ianlancetaylor]

@andreagrandi Don't use go build -i. There is no reason to use the -i option any more.

[andreagrandi]

@andreagrandi Don't use go build -i. There is no reason to use the -i option any more.

I didn't use the -i option directly. VSCode Go official extension must be using it somewhere, but I can't see it in this error messsage:

Should I open a bug in the VSCode Go extension then?

p.s: the workaround sudo chown -R <your username> /usr/local/go/pkg/darwin_amd64/ solved my issue.

[ianlancetaylor]

Should I open a bug in the VSCode Go extension then?

Sounds like it. It certainly shouldn't run go build -i by default, since, as you've discovered, it does not work in every environment.

[jayconrod]

@andreagrandi Please do file an issue at https://github.com/golang/vscode-go/issues.

Make sure to include a link to this issue and to microsoft/vscode-go#2836.

Note that microsoft/vscode-go#2836 is very closely related, but the decision there was to continue using -i because it was necessary in GOPATH mode. That flag should never be necessary in module mode though.

[andreagrandi]

@andreagrandi Please do file an issue at https://github.com/golang/vscode-go/issues.

Make sure to include a link to this issue and to microsoft/vscode-go#2836.

Note that microsoft/vscode-go#2836 is very closely related, but the decision there was to continue using -i because it was necessary in GOPATH mode. That flag should never be necessary in module mode though.

done golang/vscode-go#568