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

[thomasf]

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.

[thomasf]

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]

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

[rsc]

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]

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]

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

[karalabe]

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]

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

[tamird]

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

[ianlancetaylor]

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]

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

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

[karalabe]

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.