cmd/link: internal linker fails to build openshift/installer with "program too large, call relocation distance" and segfaults on linux/arm64 #40492
Comments
How big are we talking? If you compile it for amd64 how larger is the image? |
@davecheney ~436MB executable on arm64 with external linker, with defaults 468MB on amd64 |
That’s staggering. I thought hyperkube was large. |
TBH same here, assumed it will be in the "normal" ~100MB range, not 3-4 times larger. |
To note it is not stripped with DWARF. And disabling the DWARF have no effect on the build success. |
@gopherbot remove WaitingForInfo |
Also cc @jeremyfaller . Looks like we may have a trampoline insertion issue? |
Note that this was also present in 1.14 and 1.13, so this isn't a regression. I've tentatively put this in the 1.15 milestone, but we probably won't fix this for the initial release (it may make a point release). |
We don't have trampoline support on ARM64. We could implement it (which shouldn't be too hard). But probably too late for 1.15. |
DWARF does not matter. It is solely about program text. |
@cherrymui yeah, it would have been really weird if that had any impact @aclements it would be cool to have it fixed in the go1.15, but it seems that the GC with external linker is ok atm(in all upstream supported versions of GC). So this doesn't seem to me as really critical issue atm. |
Thanks for the follow-up. Since 1.15 is just about out the door at this point, I'll move this to 1.16. |
There is a bug with the golang internal linker for the linux/arm64 target that has yet to be fixed: golang/go#40492
There is a bug with the golang internal linker for the linux/arm64 target that has yet to be fixed: golang/go#40492
And bumping to 1.17. We should add trampolines, since this is likely to become a problem for more users in the future. |
For the record this is still issue. There are no changes with go1.16. External linker workaround still holds. |
Yes, no work is done for this in Go 1.16. My plan is to do this in 1.17. |
There is a bug with the golang internal linker for the linux/arm64 target that has yet to be fixed: golang/go#40492
If no one plans to do this next quarter, I am happy to take it. Thank you. |
I plan to do this in 1.17. But if you get ahead of me, feel free to send a CL. Thanks. |
Not sure if this is related, but trying to cross-compile to darwin/arm64 with go1.16.2 produces a similar error (but darwin/amd64 works):
|
@yselkowitz yes, that looks similar to this. |
seeing similar issue attempting to build openshift-installer on Apple M1. I believe its related:
|
Note that @rcbaus' error is with forcing CGO_ENABLED=1 and linkmode external. With CGO_ENABLED=0 and default linkmode, the error on M1 Mac is the same that I got cross-compiling from Linux, as above. |
What version of Go are you using (
go version
)?go version devel +85afa2eb19 Tue Jul 28 16:59:04 2020 +0000 linux/arm64
Also seen with go1.15rc1/1.14.6/1.13.14
Does this issue reproduce with the latest release?
Yes
What operating system and processor architecture are you using (
go env
)?linux/arm64
What did you do?
git clone https://github.com/openshift/installer
pushd installer
go build -mod=vendor -o bin/openshift-install ./cmd/openshift-install
What did you expect to see?
Build succeed.
What did you see instead?
For the record following is with the master branch go and gcc-10.1.1, gibc-2.31 and binutils-2.34 on (Fedora 32) host.
Using linkmode=external seems to work around the issue.
This reminds me of the similar issues with the external linker(on non-amd64 architectures) in the past #17028 . I'm bit surprised that this didn't got hit by any other "big binary" projects as kube, openshift,....
The text was updated successfully, but these errors were encountered: