You are trying to cross-compile from darwin/amd64 to android/amd64, but you seem to be using the native compiler rather than a cross-compiler. That can't work.

Note that for android/amd64 the default build mode is -pie which means that cmd/link will always invoke the external linker, so you always need to provide a cross-compiler.

Ah, that makes sense. Thanks. Let's call this issue about the error message, then, if this situation is not too hard to detect.

Not sure how we know whether $CC is a cross compiler.

echo "int main { return 0; }" > trivial.c
$CC -o trivial trivial.c
./trivial

If that succeeds you have a normal compiler, if it fails you have a cross-compiler. But it's a bit annoying to have to do this test each time.

@ianlancetaylor:

That test is invalid. On Exherbo, all compilation takes the cross-compilation path, including both compiling for the host architecture and multilib.

We use /usr/$TRIPLE as $PREFIX, always use $TRIPLE-prefixed $CC, etc. Your proposed test will have false positives for:

1. Native architecture, native runtime (x86_64-pc-linux-gnu on x86_64-pc-linux-gnu)
2. Native architecture, foreign runtime (x86_64-pc-linux-musl on x86_64-pc-linux-gnu)
3. Compatible architecture, native runtime (i686-pc-linux-gnu on x86_64-pc-linux-gnu)
4. Compatible architecture, foreign runtime (i686-pc-linux-musl on x86_64-pc-linux-gnu)

All four are supported and in active use on Exherbo.

@eternaleye Does that matter for the purposes of this issue, which is just about issuing a better error message?

Ah, was brought here by a google search for a similar error to that which the OP hit. Is there a ticket for that?

My specific case is I noticed (while building 1.7.1 release as an upgrade from 1.6.3) that cgo.a was not being built. This resulted in another package failing to build due to it being missing, similar to what this issue describes (1.6.3 had worked fine)

@eternaleye Let's take that question to a forum rather than complicate this issue (https://golang.org/wiki/Questions). I don't know the answer off hand.

Re @ianlancetaylor's comment above:

If that succeeds you have a normal compiler, if it fails you have a cross-compiler.

The second half is likely true. The first half is not necessarily true. If it succeeds maybe your system simply knows how to run cross-compiled binaries. For example building 32-bit binaries on a 64-bit system, or even arm binaries on an x86 system if you have a binfmt module installed to run qemu or some such.

I do agree with Minux that instead of running ./trivial we can open it and inspect the header and sanity check against the target GOOS/GOARCH. If someone wants to send a CL for that (not during a release freeze), that'd be great.

gcc -v provides the Target section, e.g: arm-linux-gnueabihf or x86_64-pc-linux-gnu so it can be used to determine whether CC is a cross-compiler or not and warn users about target mismatches (not sure that all gcc versions do that).