cmd/go: buildid broken for binaries using cgo on Mac OS 10.10.4? #12327
Labels
Milestone
Comments
|
I'm using 1.5. I definitely have d2cf46d in my |
petermattis
added a commit
to cockroachdb/c-protobuf
that referenced
this issue
Aug 25, 2015
Work around golang/go#12327 by moving the bulk of protoc into a library. We still relink protoc on every go install, but the relink only takes 1 second.
petermattis
added a commit
to cockroachdb/c-protobuf
that referenced
this issue
Aug 25, 2015
Work around golang/go#12327 by moving the bulk of protoc into a library. We still relink protoc on every go install, but the relink only takes 1 second.
petermattis
added a commit
to cockroachdb/c-protobuf
that referenced
this issue
Aug 25, 2015
Work around golang/go#12327 by moving the bulk of protoc into a library. We still relink protoc on every go install, but the relink only takes 1 second.
|
It looks like the assumption ReadBuildIDFromBinary makes that the buildid is somewhere near the start of the file is just wrong for this case. Can you tell what is actually at the front of the file? I don't remember anything like enough about macho to be useful here, unfortunately. |
|
@mwhudson I know very little about macho as well. Here is what |
|
Are we missing OS X version coverage in our builders? I mean, we ARE. But is that at fault here? |
|
The clang++ ld command line is: The I also noticed that the The above is poking around in stuff I really don't understand. |
|
Certainly seems like |
|
Yes, I thought go.o was first, and this code assumes that too. We probably
should make that true.
That said, I have vague memories of a Windows-specific bug involving the
exact order of the .o files. It was one of those "last few bugs" in an
early Go release. I can't find the CL or a comment about it though.
|
|
AFAICT, 60f783d is the commit which introduced |
|
I found the old issue. It was #2601, still open. The problem was the order
of files within an archive, not the order passed to the linker, although of
course the one might influence the other. I sent CL 16964 to see if
anything breaks if we move go.o up.
|
|
CL https://golang.org/cl/16964 mentions this issue. |
|
CL 16964 won't completely fix the issue. The location of the The location of the I wonder if trying to force a symbol into a particular location in the binary is trying to be too clever. It would be more robust to adapt/borrow some code from |
|
Looks like Github mistook |
|
Reopened. |
|
CL 17038 parses Mach-O as you suggest and reads more of the file. |
|
CL https://golang.org/cl/17038 mentions this issue. |
rsc
added a commit
that referenced
this issue
Nov 19, 2015
It's intended primarily as a torture test for OS X. Apparently Windows can't take it. Updates fix for #12327. Change-Id: If2af249ea8e2f55bff8f232dce06172e6fef9f49 Reviewed-on: https://go-review.googlesource.com/17073 Reviewed-by: Russ Cox <rsc@golang.org>
|
CL https://golang.org/cl/17127 mentions this issue. |
|
CL https://golang.org/cl/17128 mentions this issue. |
|
CL https://golang.org/cl/17126 mentions this issue. |
rsc
added a commit
that referenced
this issue
Nov 23, 2015
Does not fix #12327 but nicer anyway. Change-Id: I4ad730a4ca833d76957b7571895b3a08a6a530d4 Reviewed-on: https://go-review.googlesource.com/16964 Reviewed-by: Ian Lance Taylor <iant@golang.org> Reviewed-on: https://go-review.googlesource.com/17126
rsc
added a commit
that referenced
this issue
Nov 23, 2015
…bles This is a bit of a belt-and-suspenders fix. On OS X, we now parse the Mach-O file to find the __text section, which is arguably the more proper fix. But it's a bit worrisome to depend on a name like __text not changing, so we also read more of the initial file (now 32 kB, up from 8 kB) and scan that too. Fixes #12327. Change-Id: I3a201a3dc278d24707109bb3961c3bdd8b8a0b7b Reviewed-on: https://go-review.googlesource.com/17038 Reviewed-by: Ian Lance Taylor <iant@golang.org> Reviewed-on: https://go-review.googlesource.com/17127
rsc
added a commit
that referenced
this issue
Nov 23, 2015
It's intended primarily as a torture test for OS X. Apparently Windows can't take it. Updates fix for #12327. Change-Id: If2af249ea8e2f55bff8f232dce06172e6fef9f49 Reviewed-on: https://go-review.googlesource.com/17073 Reviewed-by: Russ Cox <rsc@golang.org> Reviewed-on: https://go-review.googlesource.com/17128 Reviewed-by: Ian Lance Taylor <iant@golang.org>
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
New with go-1.5:
go install <binary>for a binary using cgo seems to always rebuild the binary. I haven't been able to narrow down a test case, though I did verify that ReadBuildIDFromBinary is returning an empty string for the problematic binaries. A somewhat large test case isgithub.com/cockroachdb/cockroach:I would expect the second invocation to do nothing.
nmreveals:That symbol location is suspicious as the comments in
ReadBuildIDFromBinarysay that the symbol should be located at 0x2000. Compare this withstringerbuilt with go-1.5 on the same system:The text was updated successfully, but these errors were encountered: