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.