cmd/link: Xcode 8.3 dsymutil rejects our binaries
rsc opened this issue · 14 comments
In src/runtime/testdata/testprogcgo, running the final parts of a link by hand:
$ ls -l testprogcgo
-rwxr-xr-x 1 rsc eng 2008504 Mar 29 14:35 testprogcgo
$ dsymutil -f testprogcgo -o testprogcgo.dw
warning: (x86_64) /tmp/go.o unable to open object file: Invalid data was encountered while parsing the file
$ echo $?
0
$
The resulting binary is malformed.
This is the root cause of #19734, but we'll treat that issue as fixed by the workaround of not trusting dsymutil's exit status when it prints "warnings" (for backport to Go 1.8).
This issue is to fix our object files to be compatible with dsymutil, for Go 1.9.
CL https://golang.org/cl/38747 mentions this issue.
I bisected https://github.com/llvm-mirror/llvm
(I definitely don't miss c++ compile times)
The problem with go compiler starts at llvm-mirror/llvm@9a41e59
Also please notice apple's and llvm's dsymutil is different binaries.
Apple dsymutil default output is:
error: No input files.
llvml dsymutil default output is:
dsymutil: Not enough positional command line arguments specified!
Must specify at least 1 positional argument: See: ./bin/dsymutil - help
I don't know how Apple use llvm in Xcode. But I can compile go binaries with cgo on mac os 10.12.3 using llvm's dsymutil before 9a41e59, and can't compile with llvm's dsymutil after this change.
@gregory-m, thanks for tracking that down. I've got a fix pending and it is definitely related to the alignment of the DWARF segment having changed.
CL https://golang.org/cl/38855 mentions this issue.
Heh, yet the issue is closed.
Be the bot you want to see in the world.
ETA on go 1.8.1 release, so Mac developers can stop worrying about Xcode versions?
We hope this week.
CL https://golang.org/cl/39605 mentions this issue.
Cherry-picked.