Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

cmd/link: revisit dwarf in executable files on OS X #11994

Closed
thomasf opened this issue Aug 3, 2015 · 12 comments
Closed

cmd/link: revisit dwarf in executable files on OS X #11994

thomasf opened this issue Aug 3, 2015 · 12 comments

Comments

@thomasf
Copy link

thomasf commented Aug 3, 2015

This works fine with go 1.4.x. I've tried the go master branch a handful of times during the last month or so with the same result.

Error from go build:

/usr/local/go/pkg/tool/linux_amd64/link: /usr/local/go/pkg/tool/linux_amd64/link: combining dwarf failed: open /tmp/go-link-026066058/go.dwarf: no such file or directory

Environment:

GOOS=darwin GOARCH=amd64 GO15VENDOREXPERIMENT=1 CC=o64-clang  CGO_ENABLED=1

The clang toolchain in use is osxcross

@ianlancetaylor suggested to use -ldflags=-s as a work around which produced a working binary.

@ianlancetaylor ianlancetaylor added this to the Go1.5 milestone Aug 3, 2015
@thomasf
Copy link
Author

thomasf commented Aug 3, 2015

I have looked around inside osxcross now and it only supplies a dummy dsymutil so thats probably the whole reason.
Is dsymutil only used by Go since 1.5?

@ianlancetaylor
Copy link
Contributor

Yes, the use of dsymutil was added by https://golang.org/cl/10284 in May.

@rsc
Copy link
Contributor

rsc commented Aug 3, 2015

Yes, dsymutil is only used by Go since Go 1.5.
The -s fix is the correct one.
We have also run into problems with codesign not liking binaries with debug info.
Again -s is the fix.

Since there is a workaround (and the fix would be to just make the workaround be the default when using external linking), I don't believe we will make any changes to this behavior for Go 1.5.

We can reconsider for Go 1.6 if this turns out to be a very common problem, but it seems to me that having debug info in the common case is probably more important than having to add -s when doing something a bit unusual, like using osxcross or codesign.

@rsc rsc closed this as completed Aug 3, 2015
@rsc rsc changed the title linker fails when cgo cross compiling darwin in linux/go1.5b3 cmd/link: revisit dwarf in executable files on OS X Aug 3, 2015
@rsc rsc modified the milestones: Go1.6, Go1.5, Go1.6Early Aug 3, 2015
@rsc rsc reopened this Aug 3, 2015
@rsc
Copy link
Contributor

rsc commented Aug 3, 2015

Repurposing this bug to collect issues with the "dwarf in executable" code that appear during the Go 1.5 cycle. The other so far is #11887.

@ianlancetaylor
Copy link
Contributor

I suggest that when cross-compiling, we check whether dsymutil didn't generate a file, and just skip the DWARF combining in that case.

tsg pushed a commit to tsg/beats-packer that referenced this issue Sep 25, 2015
There's a go 1.5 bug that requires this:
golang/go#11994
tsg pushed a commit to tsg/beats-packer that referenced this issue Sep 25, 2015
Because the toolchain bootstraping process changed in Go 1.5,
this change imports the "pure bootstraper" from the
https://github.com/karalabe/xgo project.

There's also Go 1.5 bug that required adding the `ldflags=-s` flag
for OS X: golang/go#11994
@karalabe
Copy link
Contributor

karalabe commented Nov 5, 2015

Although the -s workaround is ok for simpler scenarios, it introduces problems when linking together multiple libraries built with it. Namely, -s strips the entire symbol table, so the produced library cannot be reused by other dependent code.

It leads to errors such as the following:

ld: internal error: atom not found in symbolIndex(__ZN6snappy17SnappyArrayWriter14AppendFromSelfEmm) for architecture x86_64

@karalabe
Copy link
Contributor

karalabe commented Nov 5, 2015

Shouldn't DWARF stipping be tied to -S instead of -s?

@tamird
Copy link
Contributor

tamird commented Nov 5, 2015

Seems like this one is going to be a breaking change. @ianlancetaylor @rsc can you guys provide some guidance?

@ianlancetaylor
Copy link
Contributor

Earlier I suggested that when cross-compiling, we check whether dsymutil didn't generate a file, and just skip the DWARF combining in that case. That still seems right to me. Does it not work around the issue as best we can?

@karalabe
Copy link
Contributor

karalabe commented Nov 5, 2015

@ianlancetaylor It seems the correct choice to me too. Just wanted you guys to know that the current workaround can break for more complex scenarios.

@gopherbot
Copy link

CL https://golang.org/cl/16702 mentions this issue.

@karalabe
Copy link
Contributor

Just to get back on this issue. The fix indeed seems to have solved the linker problems. I can now cross compile on darwin with more complex C dependencies.

@golang golang locked and limited conversation to collaborators Nov 27, 2016
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

6 participants