cmd/link: incorrect header flags for arm hard-float/soft-float #7094
Comments
|
Comment 1 by james.page@canonical.com: Link to example failed build: https://launchpadlibrarian.net/144994901/buildlog_ubuntu-saucy-armhf.golang_2%3A1.1.1-3_FAILEDTOBUILD.txt.gz |
|
Comment 2 by james.page@canonical.com: Patch to fixup headers (from Adam Conrad) Attachments:
|
the issue is easy, but the fix is not. We can't rely on host configuration to set the binary headers ABI flags (as the patch in #2 did). How can we get to know which ABI flag to use for each binary? We probably should discover that by looking at intermediate cgo outputs. another easy solution will be to disable internal linker entirely for cgo on Linux/ARM. Labels changed: added release-go1.3, repo-main. Status changed to Accepted. |
rsc
changed the title
|
Looking at the cgo intermediate outputs sounds sensible but doesn't actually work in practice because gcc does not set the correct flags. Looking for eabihf in the output of $CC -dumpmachine is the cleanest "correct" fix I can think of. For distro package builds, I think always using the external linker for cgo would be fine (although for Ubuntu specifically we could just set the flag to armhf unconditionally as we only build for that these days...) |
|
Can someone assign this to me please? |
|
I think we still want to preserve the ability to link trivial
cgo programs using internal linking.
By trivial, I mean Go programs that only uses net, or
os/user, but don't by themselves use cgo.
|
|
You mean a system which has a binary go install but no C compiler? Makes sense -- maybe the value of $CC -dumpmachine should be recorded by cgo rather than inspected by the linker? |
…s that use cgo correctly Debian and Ubuntu build infrastructure on ARM systems assumes that the ELF flags describing the float abi an executable uses matches those of the system libraries it links against. Go's linker currently always produces executables declaring that they use the soft-float ABI, but really the decision over what ABI to use is made by the C compiler during the invocation of cgo. So this records, the best way I know how, the abi that compiler uses during the cgo run and records it in a way that gets through to the linker, which can then set the flags appropriately. Fixes golang#7094 Change-Id: If0d9fc5219549dcc7910c0651017462375e01eb4
|
CL https://golang.org/cl/14860 mentions this issue. |
It is generally expected that the ELF flags of a dynamically linked executable and the libraries it links against match. Go's linker currently always produces executables with flags that do not declare a float abi (hard, soft) at all, but when cgo is involved it is unlikely that this matches the system libraries being linked against -- really the decision about ABI is made by the C compiler during the invocation of cgo. This change is basically a port of the code from binutils that parses the ".ARM.attributes" section to check for the tag that declares that the code is built for the hard-float ABI. Fixes golang#7094 Change-Id: I737c8f3b5ed4af545cfc3e86722d03eb83083402
…s that use cgo correctly It is generally expected that the ELF flags of a dynamically linked executable and the libraries it links against match. Go's linker currently always produces executables with flags that do not declare a float abi (hard, soft) at all, but when cgo is involved it is unlikely that this matches the system libraries being linked against -- really the decision about ABI is made by the C compiler during the invocation of cgo. So this records, the best way I know how, the abi that compiler uses during the cgo run and records it in a way that gets through to the linker, which can then set the flags appropriately. Fixes golang#7094 Change-Id: If0d9fc5219549dcc7910c0651017462375e01eb4
by james.page@canonical.com:
The text was updated successfully, but these errors were encountered: