Description
Historically, when handling issues like "the tools on the system we are delivering the toolchain to, for a particular target arch, have lots of individual quirks", Rust has had two primary moves:
- Allow the tools we use to be completely configured via flags
- Ship our own tool and teach the compiler to prefer that for that host/target
On macOS various systems, we are encountering reports in the wild of people having bad inadequately-built strip binaries in their PATH that cannot support all Rust compiler use-cases12 (e.g. GNU binutils that is built with only host platform support).
In particular, this means:
- sometimes
cargo run --releaseproduces binaries that get SIGKILLed on macOS - sometimes cross-compiled binaries, even between ELF/DWARF hosts and targets, have broken stacktraces, because the strip isn't aware it should be sensitive to the needs of that target platform's debugging infra.
We can try to work with Nix, Homebrew, and apparently illumos and most Linux distros to solve this problem, but if this is a persistent issue, and considering the somewhat mysterious errors that result, it may be most productive to simply ship our own copy of strip on these hosts. I believe llvm-strip gets everything right, as far as we are concerned, and would be the choice to "bless" accordingly.
Even if it has its own problems, it would be far easier to ship desired patches to binary support we control, or invite people to push fixes to upstream: we'd just need to cooperate with LLVM (or whoever else supplies this), rather than relying on every single distro cooperating perfectly with us. And I think that it's probably worth it: llvm-strip costs only about 175KB on my system, and probably a little bit of build infra, but pays for itself several times over, obviously: every Rust binary built with the toolchain, thanks to enabling strip, is a few MB lighter for its --release mode.
Footnotes
-
On macOS this is especially bad. The local toolchain comes with
llvm-stripwhich supports mach-o correctly, but in practice, no one uses the local toolchain exclusively. Yeah, XCode is the standard for merely building something, but in order to make a really complete development environment on macOS, you have to add something, like Homebrew, MacPorts, or Nix. So people on macOS are constantly injecting oddstripbinaries into their PATH that can't even support the host, leading to us using one that is flawed. These tools try to compensate for the inevitable odd system configurations that result but do so imperfectly, resulting in erroneous behavior. ↩ -
By default, it seems e.g. Nix only builds with host support, because the cost of all-targets support is about 60 more MB. I'm sure they're not the only one. 'tis a very "don't pay for what you don't need" mindset to make you install every single cross-build target individually and pay a few dozen MB each time, instead of paying double, once. ↩