One possibility is to [...] std packages would be stale, but everything could be rebuilt without a C compiler.

With this approach, does this mean that if one makes a local changes to package net (say, to debug an issue), and then builds a binary that imports net, the binary would not include the local changes to package net?

If so, this sounds bad, since it leads to programs being built that don't match the user's expectation, and the user has no way of knowing this is happening.

Interesting. I think that at this point in the release cycle we have to roll back the fix for #40042.

With this approach, does this mean that if one makes a local changes to package net (say, to debug an issue), and then builds a binary that imports net, the binary would not include the local changes to package net?

@nishanths If there are local changes to net or any other package, go build would definitely still pick those up, regardless of this issue. The SHA-256 sum of each source file is part of a package's cache key, so if anything changes, the cache key will change, and the .a file compiled earlier (whether in $GOROOT/pkg or in $GOCACHE) won't be used.

Rolling back the fix for #40042 would be unfortunate, since it can lead to subtle problems in other ways (for example, linking against cached packages that were affected by subsequently-fixed bugs, or benchmarking cgo calls that do not accurately reflect the current C compiler).

As a middle ground, would it make sense to omit the CC ID part of the build ID only for packages marked as Standard for Go 1.17? That would allow the build to continue to link against the bundled standard-library packages, but still correctly rebuild stale user packages when the C compiler changes.

(Then we could consider a more holistic fix, such as the one proposed in this issue, for Go 1.18.)

Interesting. I think that at this point in the release cycle we have to roll back the fix for #40042.

@ianlancetaylor That may be the right thing to do, though @bcmills' suggestion sounds like a good alternative, keeping most of the benefit of that fix.

We've been considering removing pre-compiled .a files from the distribution altogether. I'm planning to file a proposal for that in the next day or two. If we decide to do that, perhaps we should change CGO_ENABLED at the same time, since that change would cause the same problem.

Skipping the compiler ID for standard library packages occurred to me also. Let's do that for 1.17.

Change https://golang.org/cl/335409 mentions this issue: cmd/go: don't add C compiler ID to hash for standard library

After some internal discussion, I'd like to withdraw this issue.

Changing the default of CGO_ENABLED based on whether a C compiler is in PATH is too magical. This can result in a subtle but substantial change to how our users' code is built, so we need to be extremely cautious with a change like this.

Two issues motivated this:

• In cmd/go: build fails requiring C compiler for runtime/cgo #47215, we found that including the C compiler ID in the cache key required runtime/cgo and anything that depends on it (including net) to be rebuilt on most systems. CL 335409 seems like a good mitigation for this, so there's no longer any urgency here.
• In cmd/dist: remove precompiled .a files from binary distributions [freeze exception] #47257, we're looking for a way to remove precompiled .a files from the Go distribution. We'd like to build net without a C compiler installed without loss of functionality. That needs more investigation, but it seems like we can link and call C code via assembly trampolines, so we might not need actually cgo.

This was implemented after all in CL 450739.