cmd/link,x/build: android-arm-corellium tries to link using arm64 C toolchain

[bcmills]

In CL 472096, I am experimenting with enabling tests that use go build on android, because I don't see a good reason not to. Unfortunately, cgo linking seems to be broken on the android-arm-corellium builder.

An example failure (https://storage.googleapis.com/go-build-log/1efd1f50/android-arm-corellium_80b1a8db.log):

--- FAIL: TestIssue28429 (1.05s)
    link_test.go:106: 'go tool link -importcfg=/data/data/com.termux/files/home/tmpdir/workdir-host-android-arm64-corellium-android/tmp/TestIssue284292101675739/001/importcfg main.a' failed: exit status 1, output: /data/data/com.termux/files/home/tmpdir/workdir-host-android-arm64-corellium-android/go/pkg/tool/android_arm64/link: running gcc failed: exit status 1
        ld.lld: error: /data/data/com.termux/files/home/tmpdir/workdir-host-android-arm64-corellium-android/tmp/go-link-1516915211/go.o is incompatible with aarch64linux

It appears that for some reason the external linker thinks it is linking for arm64 instead of arm.

This builder runs on the arm64 host, and it uses the same CC value:

CC=/data/data/com.termux/files/home/clangwrap

It also explicitly sets CGO_ENABLED=1, added in CL 174857 (CC @eliasnaur @bradfitz).

---

It isn't clear to me whether this is a bug in cmd/link (failing to set a needed arch flag), or a misconfiguration in the builder itself (supplying the wrong CC value, or erroneously setting CGO_ENABLED when it should not be set).

(attn @golang/android @steeve @changkun; CC @golang/compiler)

[mknyszek]

In triage, we (C&RT) suspect this is more of a builder environment issue, but we'll keep an eye on it. (Though maybe we're passing the wrong flag or something to the C toolchain.)

[bcmills]

I think (*cmd/go/internal/work.Builder).gccArchArgs may be making unwarranted assumptions about whether the $CC in use is gcc or clang — it has lines like

if cfg.Goos == "darwin" {
	return []string{"-arch", "x86_64", "-m64"}
}

but as far as I can tell the -arch flag may be needed whenever $CC is clang or a variation thereof (in this case clangwrap) if it may be a cross-compiler, and may be invalid whenever $CC is gcc or a variation thereof (where cross-compilers are generally given per-arch executable names).

So I think this is a cmd/go bug (assuming clang or not for cross-compilation based on GOOS), but it may have a possible workaround on the builder side too (explicitly setting -arch in the CC variable, or perhaps in CGO_CFLAGS and CGO_LDFLAGS).

[bcmills]

Oh! This might also just be a bug in the test. go_android_exec explicitly sets CGO_ENABLED=0, but up until CL 472215 testenv.HasCGO was ignoring CGO_ENABLED and instead reporting whether the test binary itself was built with cgo enabled.

(That was a bug: the doc comment for HasCGO says it reports “the current system”, not “the system on which the binary was built”.)

[gopherbot]

Change https://go.dev/cl/475155 mentions this issue: cmd/link: use only the configured C compiler in TestCGOLTO