doc: clarify usage of CGO_ENABLED

[mdempsky]

I was trying to repro issue #9510. I'm on a linux/amd64 system, and I used "GOARCH=386 ./make.bash --no-clean" to setup a cross-compiler toolchain. However, subsequently running "GOARCH=386 go build issue" per iant@'s instructions yielded an unhelpful "no buildable Go source files in .../issue/a" error.

Poking into the package go/build source code, I discovered mention of "CGO_ENABLED" so I tried "GOARCH=386 CGO_ENABLED=1 go build issue". This worked to reproduce the issue.

However, trying to learn more about this setting, I found this in cmd/cgo/doc.go:

To enable cgo during cross compiling builds, set the CGO_ENABLED
environment variable to 1 when building the Go tools with make.bash.

So I inferred I was misusing it and decided to startover with "GOARCH=386 CGO_ENABLED=1 ./make.bash --no-clean" instead, but then running just "GOARCH=386 go build issue" again produced the same "no buildable Go source files" error.

Confusingly, src/make.bash also seems to mention CGO_ENABLED having some significance, but at the moment (even having poked through run.bash and grep'd the source code), I'm still not sure I entirely understand the significance.

[minux]

If you used
GOARCH=386 ./make.bash --no-clean to build Go, then
cgo should be automatically enabled if you use
$GOROOT/bin/linux_386/go, but not if you use
GOARCH=386 $GOROOT/bin/go

Whether cgo is enabled or not is being embedded into the
native Go command. And setting GOARCH to a Go command
for different GOARCH will automatically disable cgo unless
you also set CGO_ENABLED=1.

Yes, this might be confusing.

[davecheney]

Hello,

I was the one that made that change last year. There is some background in
the CL, https://codereview.appspot.com/8134043 (not as much as I had
hoped), and references issue #5141

On Thu, Jan 8, 2015 at 10:39 AM, Matthew Dempsky notifications@github.com
wrote:

I was trying to repro issue #9510
#9510. I'm on a linux/amd64 system,
and I used "GOARCH=386 ./make.bash --no-clean" to setup a cross-compiler
toolchain. However, subsequently running "GOARCH=386 go build issue" per
iant@'s instructions yielded an unhelpful "no buildable Go source files
in .../issue/a" error.

Poking into the package go/build source code, I discovered mention of
"CGO_ENABLED" so I tried "GOARCH=386 CGO_ENABLED=1 go build issue". This
worked to reproduce the issue.

However, trying to learn more about this setting, I found this in
cmd/cgo/doc.go:

To enable cgo during cross compiling builds, set the CGO_ENABLED
environment variable to 1 when building the Go tools with make.bash.

So I inferred I was misusing it and decided to startover with "GOARCH=386
CGO_ENABLED=1 ./make.bash --no-clean" instead, but then running just
"GOARCH=386 go build issue" again produced the same "no buildable Go source
files" error.

Confusingly, src/make.bash also seems to mention CGO_ENABLED having some
significance, but at the moment (even having poked through run.bash and
grep'd the source code), I'm still not sure I entirely understand the
significance.

—
Reply to this email directly or view it on GitHub
#9530.

[paralin]

I'm having the problem at the moment with this error, even when I define CGO_ENABLED when cross compiling a go program, as well as when I try to compile the Go compiler with CGO_ENABLED.

What's the correct way to do this?

I'm going amd64 -> arm by the way.

[ianlancetaylor]

@paralin Please ask questions on the mailing list golang-nuts@googlegroups.com, rather than dropping a question into an issue. Thanks.

I'm not sure what error you mean here. In your e-mail to golang-nuts, please say exactly what you did, exactly what happened, and what you expected to happen instead.

[gopherbot]

CL https://golang.org/cl/12603 mentions this issue.