New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

cmd/go: provide better error message when cross-compiling toolchain is required #16395

Open
josharian opened this Issue Jul 16, 2016 · 11 comments

Comments

Projects
None yet
8 participants
@josharian
Contributor

josharian commented Jul 16, 2016

  1. What version of Go are you using (go version)?

510fb63: tip between 1.7rc1 and 1.7rc2

  1. What operating system and processor architecture are you using (go env)?
GOARCH="amd64"
GOBIN="/Users/josh/bin"
GOEXE=""
GOHOSTARCH="amd64"
GOHOSTOS="darwin"
GOOS="darwin"
GOPATH="/Users/josh"
GORACE=""
GOROOT="/Users/josh/go/tip"
GOTOOLDIR="/Users/josh/go/tip/pkg/tool/darwin_amd64"
CC="clang"
GOGCCFLAGS="-fPIC -m64 -pthread -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -fdebug-prefix-map=/var/folders/pp/0010hzld5b12h_92j5th082r0000gn/T/go-build629103623=/tmp/go-build -gno-record-gcc-switches -fno-common"
CXX="clang++"
CGO_ENABLED="1"
  1. What did you do?

GOOS=android GOARCH=amd64 go install std cmd

  1. What did you expect to see?

Success.

  1. What did you see instead?
# cmd/addr2line
warning: unable to find runtime/cgo.a
/Users/josh/go/tip/pkg/tool/darwin_amd64/link: running clang failed: exit status 1
ld: unknown option: -z
clang: error: linker command failed with exit code 1 (use -v to see invocation)

# cmd/asm
warning: unable to find runtime/cgo.a
/Users/josh/go/tip/pkg/tool/darwin_amd64/link: running clang failed: exit status 1
ld: unknown option: -z
clang: error: linker command failed with exit code 1 (use -v to see invocation)

and so on

Running GOOS=android GOARCH=amd64 go install -ldflags=-v std cmd:

# cmd/cgo
HEADER = -H4 -T0x401000 -D0x0 -R0x1000
searching for runtime.a in $WORK/runtime.a
searching for runtime.a in /Users/josh/go/tip/pkg/android_amd64_shared/runtime.a
searching for runtime/cgo.a in $WORK/runtime/cgo.a
searching for runtime/cgo.a in /Users/josh/go/tip/pkg/android_amd64_shared/runtime/cgo.a
warning: unable to find runtime/cgo.a
 0.00 deadcode
 0.03 pclntab=599713 bytes, funcdata total 119620 bytes
 0.03 dodata
 0.04 dwarf
 0.07 symsize = 0
 0.16 reloc
 0.17 asmb
 0.17 codeblk
 0.17 datblk
 0.18 sym
 0.18 symsize = 122040
 0.19 symsize = 122088
 0.19 dwarf
 0.21 headr
host link: "clang" "-m64" "-gdwarf-2" "-Wl,-z,relro" "-pie" "-o" "/var/folders/pp/0010hzld5b12h_92j5th082r0000gn/T/go-build962217633/cmd/cgo/_obj/exe/a.out" "-rdynamic" "-Qunused-arguments" "/var/folders/pp/0010hzld5b12h_92j5th082r0000gn/T/go-link-534529285/go.o"
/Users/josh/go/tip/pkg/tool/darwin_amd64/link: running clang failed: exit status 1
ld: unknown option: -z
clang: error: linker command failed with exit code 1 (use -v to see invocation)

and so on

This also causes GOOS=android GOARCH=amd64 ./bootstrap.bash to fail.

Maybe this is expected (?), but it doesn't seem right to me.

@ianlancetaylor

This comment has been minimized.

Contributor

ianlancetaylor commented Jul 17, 2016

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.

@josharian

This comment has been minimized.

Contributor

josharian commented Jul 17, 2016

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

@josharian josharian changed the title from cmd/go: cannot link android/amd64 on darwin/amd64: ld: unknown option: -z to cmd/go: provide better error message when cross-compiling toolchain is required Jul 17, 2016

@quentinmit quentinmit added this to the Go1.8 milestone Jul 19, 2016

@quentinmit quentinmit added the NeedsFix label Oct 6, 2016

@rsc

This comment has been minimized.

Contributor

rsc commented Oct 21, 2016

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

@ianlancetaylor

This comment has been minimized.

Contributor

ianlancetaylor commented Oct 21, 2016

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.

@minux

This comment has been minimized.

Member

minux commented Oct 25, 2016

@rsc rsc modified the milestones: Go1.9, Go1.8 Nov 11, 2016

@eternaleye

This comment has been minimized.

eternaleye commented Nov 13, 2016

@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.

@ianlancetaylor

This comment has been minimized.

Contributor

ianlancetaylor commented Nov 13, 2016

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

@eternaleye

This comment has been minimized.

eternaleye commented Nov 13, 2016

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)

@ianlancetaylor

This comment has been minimized.

Contributor

ianlancetaylor commented Nov 14, 2016

@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.

@rsc

This comment has been minimized.

Contributor

rsc commented Jun 22, 2017

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.

@rsc rsc modified the milestones: Go1.10, Go1.9 Jun 22, 2017

@rsc rsc modified the milestones: Go1.10, Go1.11 Dec 1, 2017

@gopherbot gopherbot modified the milestones: Go1.11, Unplanned May 23, 2018

@amenzhinsky

This comment has been minimized.

Contributor

amenzhinsky commented Jul 22, 2018

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).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment