我的Go工具是否为错误的架构而构建？

我是Go语言的忠实粉丝，现在我正在尝试探索除x86/amd64之外的其他体系结构。我为ARM构建Go，并且似乎对该目标有很好的支持。所有的库都成功构建，并且测试失败（因为它试图在我的amd64系统上运行ARM测试二进制文件）。我的Go工具是否为错误的架构而构建？

毕竟，我在我的$GOBIN文件夹中有5g/5l，它们生成有效且正常的ARM二进制文件。但是发生了什么其他的围棋工具：

5a:  ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.9, not stripped 
5c:  ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.9, not stripped 
5g:  ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.9, not stripped 
5l:  ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.9, not stripped 
6cov:  ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.9, not stripped 
6nm:  ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.9, not stripped 
6prof:  ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.9, not stripped 
cgo:  ELF 32-bit LSB executable, ARM, version 1 (SYSV), statically linked, not stripped 
ebnflint: ELF 32-bit LSB executable, ARM, version 1 (SYSV), statically linked, not stripped 
godefs: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.9, not stripped 
godoc:  ELF 32-bit LSB executable, ARM, version 1 (SYSV), statically linked, not stripped 
gofix:  ELF 32-bit LSB executable, ARM, version 1 (SYSV), statically linked, not stripped 
gofmt:  ELF 32-bit LSB executable, ARM, version 1 (SYSV), statically linked, not stripped 
goinstall: ELF 32-bit LSB executable, ARM, version 1 (SYSV), statically linked, not stripped 
gomake: POSIX shell script, ASCII text executable 
gopack: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.9, not stripped 
gopprof: a perl script, ASCII text executable 
gotest: ELF 32-bit LSB executable, ARM, version 1 (SYSV), statically linked, not stripped 
gotry:  a bash script, ASCII text executable 
gotype: ELF 32-bit LSB executable, ARM, version 1 (SYSV), statically linked, not stripped 
govet:  ELF 32-bit LSB executable, ARM, version 1 (SYSV), statically linked, not stripped 
goyacc: ELF 32-bit LSB executable, ARM, version 1 (SYSV), statically linked, not stripped 
hgpatch: ELF 32-bit LSB executable, ARM, version 1 (SYSV), statically linked, not stripped

看到了吗？ cgo是ARM二进制文件，gofix和gofmt也是ARM二进制文件。我认为如果我提供$GOHOSTOS/$GOHOSTARCH变量，我会交叉编译我的应用程序吗？如何获得cgo适用于ARM目标？

来源

2012-01-11 zserge

我不知道你问这里有什么，你有一个ARM二进制CGO和你问如何使它在ARM工作？你能澄清一下这个问题吗？ – 2012-01-11 17:22:04

我的主机是amd64，编译器和链接器是am64，但cgo是ARM。我虽然cgo运行在主机PC上，而不是目标设备上，所以我期望它也是amd64。纠正我，如果我错了。那么，问题是应该为目标体系结构编译Go工具，以及为主机PC编译什么？ – zserge 2012-01-11 17:28:02

Go linux/arm端口不完整。例如，linux/arm的cgo运行时未实现。见$GOROOT/src/pkg/runtime/cgo/gcc_arm.S和$GOROOT/src/pkg/runtime/cgo/gcc_linux_arm.c。

[cgo on arm.]它不计划转到1.

来源

2012-01-11 18:16:56 peterSO

悲伤，但真实:(你知道关于gcc-go支持ARM的任何事情（如果有一种方法可以将我的Go代码与使用ARM target的C代码连接起来）？ – zserge 2012-01-11 18:41:03

我的Go工具是否为错误的架构而构建？

回答

相关问题