cmd/go: automatically disable cgo on systems with no C compiler

The documentation for cgo has always said:

> The cgo tool is enabled by default for native builds
> on systems where it is expected to work.

Following the spirit of that rule, this CL disables cgo by default
on systems where $CC is unset and the default C compiler
(clang or gcc) is not found in $PATH.

This CL makes builds of Go code on systems with no C compiler
installed automatically fall back to non-cgo mode.
For example, if building a Go program using package net
in a stripped down Linux container, that build will now run
with cgo disabled, instead of attempting the build with cgo enabled
and only succeeding if the right pre-compiled .a files happen to
be loaded into the container.

This CL makes it safe to drop the pre-compiled .a files
from the Go distribution. Systems that don't have a C compiler
will simply disable cgo when building new .a files for that system.

In general keeping the pre-compiled .a files working in cgo mode
on systems without C compilers has had only mixed success due
to the precise build cache. Today we have had to disable various
checks in the precise build cache so that distributed .a files look
up-to-date even if the current machine's C compiler is a different
version than the one used when packaging the distribution.
Each time we improve precision we have a decent chance of
re-invalidating the files. This CL, combined with dropping the .a files
entirely, will let us re-enable those checks and ensure that the
.a files used in a build actually match the C compiler being used.

On macOS, the distributed .a files for cgo-dependent packages
have been stale (not actually used by the go command) since the
release of Go 1.14 in February 2020, due to CL 216304 setting
a CGO_CFLAGS environment variable that won't match the default
setting on users machines. (To keep the distributed .a files working,
that CL should have instead changed the default in the go command.)
The effect is that for the past six Go releases (!!!), the go command
has been unable to build basic programs like src/net/http/triv.go
on macOS without either disabling cgo or installing Xcode's C compiler.
This CL fixes that problem by disabling cgo when there's no C compiler.
Now it will once again be possible to build basic programs with just
a Go toolchain installed.

In the past, disabling cgo on macOS would have resulted in subpar
implementations of crypto/x509, net, and os/user, but as of CL 449316
those packages have all been updated to use libc calls directly,
so they now provide the same implementation whether or not cgo is enabled.
In the past, disabling cgo on macOS would also have made the
race detector unusable, but CL 451055 makes the race detector
work on macOS even when cgo is disabled.

On Windows, none of the standard library uses cgo today, so all
the necessary .a files can be rebuilt without a C toolchain,
and there is no loss of functionality in the standard library when
cgo is disabled. After this CL, the race detector won't work on
Windows without a C toolchain installed, but that turns out to be
true already: when linking race-enabled programs, even if the Go linker
does not invoke the host linker, it still attempts to read some of the
host C toolchain's .a files to resolve undefined references.

On Unix systems, disabling cgo when a C compiler is not present
will mean that builds get the pure Go net resolver, which is used
by default even in cgo builds when /etc/resolv.conf is simple enough.
It will also mean they get the pure os/user code, which reads
/etc/passwd and /etc/group instead of using shared libraries,
and therefore it may miss out on other sources of user information
such as LDAP. The race detector also will not work without a C compiler.
This would be dire except that nearly all Unix systems have a C compiler
installed by default, and on those that don't it is trivial to add one.
In particular, the vast majority of Go developers running on Linux
and other Unix systems will already have a C compiler and will be
unaffected.

Change-Id: I491e8a022fe3a64022e9dc593850d483a0d353fa
Reviewed-on: https://go-review.googlesource.com/c/go/+/450739
Reviewed-by: Bryan Mills <bcmills@google.com>
Auto-Submit: Russ Cox <rsc@golang.org>
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>

diff --git a/src/cmd/cgo/doc.go b/src/cmd/cgo/doc.go
index 1c24b76407fa170a2cbc7d90e51c5def33b74977..70685c741097a441cb064a3124b24ab9e047ff49 100644 (file)
--- a/src/cmd/cgo/doc.go
+++ b/src/cmd/cgo/doc.go
@@ -119,8 +119,10 @@ specified by a -I flag), then "#include <foo/bar.h>" will always find the
 local version in preference to any other version.
 
 The cgo tool is enabled by default for native builds on systems where
-it is expected to work. It is disabled by default when
-cross-compiling. You can control this by setting the CGO_ENABLED
+it is expected to work. It is disabled by default when cross-compiling
+as well as when the CC environment variable is unset and the default
+C compiler (typically gcc or clang) cannot be found on the system PATH.
+You can override the default by setting the CGO_ENABLED
 environment variable when running the go tool: set it to 1 to enable
 the use of cgo, and to 0 to disable it. The go tool will set the
 build constraint "cgo" if cgo is enabled. The special import "C"

diff --git a/src/cmd/go/internal/cfg/cfg.go b/src/cmd/go/internal/cfg/cfg.go
index 30acde0a5a500b5b091802051339bcbb86478a5e..3257140515030b593b5b1f0e57c1dd724ded9a72 100644 (file)
--- a/src/cmd/go/internal/cfg/cfg.go
+++ b/src/cmd/go/internal/cfg/cfg.go
@@ -14,6 +14,7 @@ import (
        "internal/cfg"
        "io"
        "os"
+       "os/exec"
        "path/filepath"
        "runtime"
        "strings"
@@ -148,7 +149,21 @@ func defaultContext() build.Context {
                // go/build.Default.GOOS/GOARCH == runtime.GOOS/GOARCH.
                // So ctxt.CgoEnabled (== go/build.Default.CgoEnabled) is correct
                // as is and can be left unmodified.
-               // Nothing to do here.
+               //
+               // All that said, starting in Go 1.20 we layer one more rule
+               // on top of the go/build decision: if CC is unset and
+               // the default C compiler we'd look for is not in the PATH,
+               // we automatically default cgo to off.
+               // This makes go builds work automatically on systems
+               // without a C compiler installed.
+               if ctxt.CgoEnabled {
+                       if os.Getenv("CC") == "" {
+                               cc := DefaultCC(ctxt.GOOS, ctxt.GOARCH)
+                               if _, err := exec.LookPath(cc); err != nil {
+                                       ctxt.CgoEnabled = false
+                               }
+                       }
+               }
        }
 
        ctxt.OpenFile = func(path string) (io.ReadCloser, error) {

diff --git a/src/cmd/go/testdata/script/autocgo.txt b/src/cmd/go/testdata/script/autocgo.txt
new file mode 100644 (file)
index 0000000..522eaf4
--- /dev/null
+++ b/src/cmd/go/testdata/script/autocgo.txt
@@ -0,0 +1,26 @@
+# Test automatic setting of CGO_ENABLED based on $CC and what's in $PATH.
+
+[!cgo] skip
+[cross] skip
+
+# Assume we're on a system that can enable cgo normally.
+env CGO_ENABLED=
+go env CGO_ENABLED
+stdout 1
+
+# Clearing CC and removing everything but Go from the PATH should disable cgo: no C compiler anymore.
+env CC=
+env PATH=$GOROOT/bin
+go env CGO_ENABLED
+stdout 0
+
+# Setting CC should re-enable cgo.
+env CC=cc
+go env CGO_ENABLED
+stdout 1
+
+# So should setting CGO_ENABLED.
+env CC=
+env CGO_ENABLED=1
+go env CGO_ENABLED
+stdout 1