This appears to have started at or around CL 454836, which changed cmd/dist to always build cmd without cgo enabled.

(attn @golang/compiler @golang/ios)

@cherrymui points out that this is related to #31544. It's not obvious to me whether this failure mode (on ios) is the same as the typestate bug described in #31544 (comment), or a separate bug (perhaps in cmd/link).

It isn't clear to me whether the ios build with CGO_ENABLED=0 really requires the runtime/cgo package or not.

To be clear, the loadinternal: cannot find runtime/cgo is printed by the linker, but it is not an error. It does't make the linking process fail, and the result binaries often runs fine. ("often" doesn't mean nondeterministic. I say it because it is not a well tested and well supported configuration.)

The last "ok" on the iOS builder https://build.golang.org/log/4c18d54f1d9bc8e08844d19e57b7873640c2729e also has the message for go_bootstrap (not other binaries), and it worked fine. (I'm pretty sure this was the case for quite some time, at least a couple of years.)

It isn't clear to me whether the ios build with CGO_ENABLED=0 really requires the runtime/cgo package or not.

Currently ios build requires external linking. I'm not sure we explicitly say external linking requires the runtime/cgo package. But as the C linker will likely pull in C stuff to the binary, it is pretty much a C/Go mixed binary, linking in runtime/cgo seems reasonable. If I understand correctly cmd/go tries to add runtime/cgo dependency when external linking, but sometimes doesn't? (I think that is #31544.)

It might be possible to make ios internal linking work. But I'm not sure it's worth it, as users for iOS build use external linking, as the Go code would be linked with C/objective-C/swift/etc. for their iOS app.

Or, maybe we could make sure external linking work without runtime/cgo, document it and test it. This would also fix #31544. Not sure how hard that would be (on all platforms). Also not sure it's worth it, as most users don't do this? And the C toolchain (C linker) is used anyway, so disable runtime/cgo doesn't to help much.

I'm not sure this is a linker bug. Unless we decide to implement internal linking on iOS.

This also occurs on the android-.*-emu builders today — we just happened not to notice because the rest of the build and test cycle somehow succeeds anyway:
https://build.golang.org/log/1575c55e51b0fcee52b35365d413fbeb94eee305

To me, that reinforces that the log message is not appropriate — it adds a huge amount of noise that can bury the real errors (such as in https://storage.googleapis.com/go-build-log/b968f088/android-amd64-emu_65dfd1a1.log).

Change https://go.dev/cl/463739 mentions this issue: cmd/dist: leave cgo enabled if external linking is required

Or, I guess, to put it a different way: if runtime/cgo is actually needed, the linker should emit a hard error (and exit with a nonzero status), not a warning.

If we want to emit an error, I'd hope

• decide explicitly external linking requires cgo, and document it somewhere
• fix cmd/go: spurious error message when external linking a pure Go program #31544

Otherwise go build -ldflags=-linkmode=external works today on some platforms but will be broken if we emit an error.