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 assumes xcrun 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.
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.
apple macos sysroot from xcode 12.1 (and 12.5 for arm64)
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 --print-prog-name would work fine actually, verifying with my toolchain it does the right thing.
In this scenario the failures are xcrun dsymutil and xcrun strip
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.