Change:
let strip = sess.opts.cg.strip; if sess.target.is_like_osx { <del> let stripcmd = "/usr/bin/strip"; </del> <ins> // Use system `strip` when running on host macOS. // <https://github.com/rust-lang/rust/pull/130781> let stripcmd = if cfg!(target_os = "macos") { "/usr/bin/strip" } else { "strip" }; </ins> match (strip, crate_type) { (Strip::Debuginfo, _) => { strip_symbols_with_external_utility(sess, stripcmd, out_filename, Some("-S"))

Discussion:
<!-- Thank you for filing a regression report! A regression is something that changed between versions of Rust but was not supposed to. Please provide a short summary of the regression, along with any information you feel is relevant to replicate it. --I cross-compile code for Darwin from Linux, which now fails due to the path being hard-coded in latest nightly, which I believe is caused by this PR I expected to see this happen: successful compilation Instead, this happened: I'm not sure why was chosen as the to use, as an end user - that is surprising, in fact I would have expected the from the environment to be used by default. If the intention is to set a default to a hardcoded path, then it looks like a configuration option must be provided. Alternatively, perhaps could use if found and otherwise use from environment? <!-- Provide the most recent version this worked on, for example: It most recently worked on: Rust 1.47 --It most recently worked on: 1.80.1 <!-- Provide the version you are using that has the regression. --: <!-- If you know when this regression occurred, please add a line like below, replacing with one of stable, beta, or nightly. modify labels: +regression-from-stable-to-nightly -regression-untriaged --
(The results are not exactly the same, but things are broken for the same cause.)
no, that's a different issue, since does work fine on Linux to strip Darwin binaries. The issue here is the hardcoded path introduced a week ago
Oh, sorry, I missed the information that that used to work. (In any case, I think the correct solution to these problems is the same one: )
indeed, LLVM works great for my use case, on current , however, there is no way to make sure it's used other than explicitly putting the binary in . Will land before 1.83? I don't think should land in a release and seems that it currently targets 1.83
cc and Not sure how to solve the strip situation...
Also check that the host is darwin too?
how hard is it to implement "our own" (based on crates) Mach-O stripping instead of using the command? Using the command leads to so many problems.. (on all platforms :D)
If you are using binutils strip to strip arm64 macOS binaries, it does not work fine.

It produces broken binaries with invalid code signature. On arm64 macOS mandates the use of code signatures, so "unsigned" binaries use an ad-hoc code signature, but binutils seems to forget to update the ad-hoc code signature when modifying binaries. This is exactly the problem fixed by forcing XCode's strip to be used instead.
I have been compiling Mac binaries on Linux for over a year now and I originally have experienced code signatures being broken by GNU strip on aarch64 darwin binaries myself ( IIRC it only happens for binaries that require particular MacOS frameworks). I just tried to use 2 different s on a x86_64-linux box directly to strip a binary compiled with on arm Mac and here's what I got, however: GNU strip: - the binary still works LLVM strip: success and stripped binary (I gave it a debug build with over 100k lines in ) For reference: GNU strip: LLVM strip: So clearly LLVM works just fine for stripping Mac binaries.
Ah, right. LLVM's strip should work fine.
WG-prioritization assigning priority (). label -I-prioritize +P-high
Opened to fix this directly, in case ends up taking some time.