cmd/link: fails on Ubuntu Xenial due to unsupported relocations on 386, amd64 #13114
Comments
|
/cc @ianlancetaylor |
|
I'll take this one, Ubuntu is partly my fault. @jaccarmac can you please include complete instructions to reproduce your setup so I can build a replica environment. Can you also include the complete output you receive along the way. |
|
My Unix piping isn't working for the build output, so I'll add it when I figure that out. |
|
Thanks. Can you also check that On Sat, Oct 31, 2015 at 4:02 PM, Jacob MacDonald [email protected]
|
|
|
|
Same failure with |
|
If you're using linux, or actually anything that isn't windows, you should never set GOROOT. |
|
It's my understanding that if you install the tools in a non-standard place you have to set it. Is that not the case any more? |
|
That is correct, but my recommendation is to not do that. If you use the tarball from the website, installed to the recommended location, you don't need to set GOROOT. If you build from source, then the correct value will be burnt in at compile time. If you build from source, but want to have the files in a different final location, then set GOROOT_FINAL and move the contents afterwards. Don't set GOROOT, it leads to problems 99 times out of 100.
|
|
Thanks! Last time I was building from source the value didn't get baked in and needed to be set if the path was outside |
There's the full build log. |
|
Thank you for confirming. Can you please attach the full output of your build attempt.
|
|
Could you please include the command you invoked
|
|
|
|
What version of ld or binutils do you have ? While go does not require a c compiler, cgo does, and will be expected by default on Intel platforms. What c compiler do you have installed?
|
|
What is in /tmp/go ? Is it go 1.4 ?
|
|
|
|
What version of the Go toolchain are you building? |
|
Do you have CGO_ENABLED=0 set in the environment? I think this error can only happen when using internal linking. Do you have CC set in the environment? The relocation number 42 is not defined for x86_64, and it is implausible that it would be found in an x86_64 GNU/Linux ELF file (the 298 is just 42 + 256 and has to do with the Go linker's internal representation). It would be normal to find it in an ARM or PPC64 ELF file. The incorrect file is in the archive /home/jaccarmac/local/golang/pkg/linux_amd64/runtime/cgo.a. Run |
|
I can't upload |
|
Thanks. I see that spoke too quickly. Relocation 42 was added last week: https://sourceware.org/ml/binutils/2015-10/msg00186.html . You must be using a very up to date toolchain. I think the Go build is using internal linking because the only external objects are from the runtime/cgo package. It would be helpful if you could see whether this change fixes the problem: https://golang.org/cl/16529 . Thanks. |
|
CL https://golang.org/cl/16529 mentions this issue. |
|
LGTM |
|
This is needed for Go to build from source with a new toolchain (i.e. the current devel version of Ubuntu). Does that make it a candidate for 1.5.2? |
|
I think so, and the patch is small. Added to 1.5.2 milestone. |
rsc
changed the title
|
CL https://golang.org/cl/16982 mentions this issue. |
The GNU binutils recently picked up support for new 386/amd64 relocations. Add support for them in the Go linker when doing an internal link. The 386 relocation R_386_GOT32X was proposed in https://groups.google.com/forum/#!topic/ia32-abi/GbJJskkid4I . It can be treated as identical to the R_386_GOT32 relocation. The amd64 relocations R_X86_64_GOTPCRELX and R_X86_64_REX_GOTPCRELX were proposed in https://groups.google.com/forum/#!topic/x86-64-abi/n9AWHogmVY0 . They can both be treated as identical to the R_X86_64_GOTPCREL relocation. The purpose of the new relocations is to permit additional linker relaxations in some cases. We do not attempt to support those cases. While we're at it, remove the unused and in some cases out of date _COUNT names from ld/elf.go. Fixes #13114. Change-Id: I34ef07f6fcd00cdd2996038ecf46bb77a49e968b Reviewed-on: https://go-review.googlesource.com/16529 Reviewed-by: Minux Ma <[email protected]> Reviewed-on: https://go-review.googlesource.com/16982 Run-TryBot: Austin Clements <[email protected]> Reviewed-by: Ian Lance Taylor <[email protected]> Reviewed-by: Russ Cox <[email protected]>
Merge the latest upstream Go master. The main reason for this merge is to get https://go-review.googlesource.com/#/c/16529/, which is required to build Go with a newer system toolchain. See golang/go#13114. The only RISC-V change is moving the register space after the new MIPS space. Change-Id: I1168bfea63366f99cc1241b19d15cdacdfb886bf
|
I'm marking this issue as 1.4.4, because it breaks building Go 1.4.3 with CGO_ENABLED=1. If we ever do a 1.4.4 release, we should include the fix for this issue. |
|
In pkgsrc, we keep Go 1.4 around as lang/go14, so that you have a version to bootstrap from. It turns out that Go 1.4.3 does not compile any more on NetBSD-current, see above. @ryoon has provided a patch in https://gnats.netbsd.org/50777. Should I send this as a CL? |
|
If we just need to keep Go 1.4 available as bootstrap compiler for newer
versions,
we can just support CGO_ENABLED=0 build of Go 1.4.
|
|
@bsiegert and anybody else reading this issue: what @minux is saying is: arrange to build lang/go14 with CGO_ENABLED=0 set in the environment. Then you won't run into this bug. Yes, if we do have to make a 1.4.4 release, we should include this fix. But this by itself does not seem to me like a sufficient reason to make 1.4.4 release. |
Patch from Ryo Onodera in PR pkg/50777. The upstream bug report is golang/go#13114. Bump PKGREVISION.
|
Thanks for fixing it in pkgsrc, several people were investigating NetBSD-current breakage simultaneously. |
The go linker barfed on the new relocation types emitted by binutils 2.26. golang/go#13114 http://hydra.nixos.org/build/32554876
The go linker barfed on the new relocation types emitted by binutils 2.26. golang/go#13114 http://hydra.nixos.org/build/32554876 (cherry picked from commit ff69fc6)
To avoid this issue: golang/go#13114
* libcap-dev is needed for acmetool. * for cgo see golang/go#13114
It now requires an installation of go 1.4.x to bootstrap the build. We set CGO_ENABLED=0 when building the bootstrap go compiler because go 1.4.3 won't build with a newer GNU toolchain: golang/go#13114. It didn't cause a problem for me on Ubuntu 14.04, but this will prevent it from breaking in the future. We don't need cgo in the bootstrap compiler. The other change is that the go build system no longer allows us to pass a command with arguments for CC_FOR_TARGET. I opened a ticket for it: golang/go#15457. We need -I and -L arguments in the mac build so that gcc gan find its headers and libraries. So we wrap up the arguments in a shell script and use the shell script as CC_FOR_TARGET.
It now requires an installation of go 1.4.x to bootstrap the build. We set CGO_ENABLED=0 when building the bootstrap go compiler because go 1.4.3 won't build with a newer GNU toolchain: golang/go#13114. It didn't cause a problem for me on Ubuntu 14.04, but this will prevent it from breaking in the future. We don't need cgo in the bootstrap compiler. The other change is that the go build system no longer allows us to pass a command with arguments for CC_FOR_TARGET. I opened a ticket for it: golang/go#15457. We need -I and -L arguments in the mac build so that gcc gan find its headers and libraries. So we wrap up the arguments in a shell script and use the shell script as CC_FOR_TARGET.
I am on the
devel(xenial) channel now, but the error started popping up before the 15.10 release. Standard Linux AMD64 build. Building frommasterwith the most recent binary release (1.5.1) asGOROOT_BOOTSTRAP.git reset --hard origin/master git clean -fxd GOROOT_BOOTSTRAP=$HOME/tmp/go ./all.bashThe text was updated successfully, but these errors were encountered: