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

Comments

Projects
None yet
6 participants
@thomasf
Copy link

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

This comment has been minimized.

Copy link
Author

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

This comment has been minimized.

Copy link
Contributor

commented Aug 3, 2015

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

@rsc

This comment has been minimized.

Copy link
Contributor

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 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

This comment has been minimized.

Copy link
Contributor

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

This comment has been minimized.

Copy link
Contributor

commented Aug 3, 2015

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

@zimbatm zimbatm referenced this issue Aug 30, 2015

Closed

go: 1.5 darwin #9558

tsg added a commit to tsg/beats-packer that referenced this issue Sep 25, 2015

Added -ldflags=-s to the OSX cross-compile
There's a go 1.5 bug that requires this:
golang/go#11994

tsg added a commit to tsg/beats-packer that referenced this issue Sep 25, 2015

Updated Go to version 1.5.1
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

This comment has been minimized.

Copy link
Contributor

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

This comment has been minimized.

Copy link
Contributor

commented Nov 5, 2015

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

@tamird

This comment has been minimized.

Copy link
Contributor

commented Nov 5, 2015

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

@ianlancetaylor

This comment has been minimized.

Copy link
Contributor

commented Nov 5, 2015

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

This comment has been minimized.

Copy link
Contributor

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

This comment has been minimized.

Copy link

commented Nov 8, 2015

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

@karalabe

This comment has been minimized.

Copy link
Contributor

commented Nov 20, 2015

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.
You can’t perform that action at this time.