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: allow configuration of dsymutil and strip for darwin/mach-o linking #47316
Comments
If as you say you are planning on writing a shim xcrun, would this not take care of the problems you describe? Putting additoinal knobs/controls into the linker would mainly just make it more complicated and hard to understand (for example, for the 99% of folks not doing cross compilation, they might think that they need to specify a dsymutil path, or something to this effect). |
I mean it would solve the issue in a very annoying way, in general this is a somewhat odd inconsistency given how the rest of the external c toolchain tools are configurable and hardcoding these tools kind of makes the toolchain non-hermetic, or at least requires some very non-obvious work to make hermetic, even if host is also darwin. |
trying to force xcrun in the path, I'm now running into another issue... #43783 due to how bazel works pretty much everything is relative to a execution root...so the go invocation sees that the xcrun which is added in the c++ toolchain is relative and complains... |
@chancila could you share more information about your C cross toolchain? What tools are included and how are they named? Thanks. We used to just run Maybe we could use |
I'm exercising this whole thing through bazel and rules_go...the fundamental issue is that the go linker tries to use xcrun when targeting mach binaries but it probably needs a fallback path when the linker/toolchain is hosted on non-macos systems rather than blindly using xcrun. I think In this scenario the failures are I have successfully managed to cgo cross compile for both arm64 and amd64 by adding a shim xcrun wrapper in my system to /usr/bin globally as a hack, I would prefer to not have to do this as the toolchain is otherwise hermetic to the build and handled by bazel without modifying the system tools at all. |
@chancila thanks! I think I'd go with |
Change https://golang.org/cl/336769 mentions this issue: |
What version of Go are you using (
go version
)?1.16.6
Does this issue reproduce with the latest release?
yes
What operating system and processor architecture are you using (
go env
)?go env
OutputWhat did you do?
I am cross-compiling a darwin executable from linux with cgo enabled. I have successfully compiled everything but the link step fails due to
xcrun
missing since the go link command assumesxcrun
exists if targeting darwin/mach when it really should probably only assume that if targeting darwin and host is darwin. I'm currently planning to work around this by creating a shim xcrun however having the ability to directly set these tools would be cleaner and easier to integrate with other build systems (namely bazel which I'm using in this case). The underlying tools have equivalents in open source llvm so they are not exclusive to macos hosts.The code in question https://github.com/golang/go/blob/master/src/cmd/link/internal/ld/lib.go#L1643 should allow configuration of the tool in some way so that this use-case can be covered.
What did you expect to see?
Successful build
What did you see instead?
Linker error from
ld/lib.go
:Exitf("%s: running dsymutil failed: %v\n%s", os.Args[0], err, out)
due to missing xcrunThe text was updated successfully, but these errors were encountered: