Hard-coded strip path breaks Linux -> Darwin builds

[rvolosatovs]

I cross-compile code for Darwin from Linux, which now fails due to the strip path being hard-coded in latest nightly, which I believe is caused by this PR #130781

I expected to see this happen: successful compilation

Instead, this happened:

error: unable to run `/usr/bin/strip`: No such file or directory (os error 2)

https://github.com/rvolosatovs/nixify/actions/runs/11163623704/job/31031050404?pr=265

I'm not sure why /usr/bin/strip was chosen as the strip to use, as an end user - that is surprising, in fact I would have expected the strip 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 cargo could use /usr/bin/strip if found and otherwise use strip from environment?

Version it worked on

It most recently worked on: 1.80.1

Version with regression

rustc --version --verbose:

cargo 1.83.0-nightly (80d82ca22 2024-09-27)

[taiki-e]

Duplicate of #114411

(The results are not exactly the same, but things are broken for the same cause.)

[rvolosatovs]

Duplicate of #114411

@taiki-e no, that's a different issue, since strip does work fine on Linux to strip Darwin binaries. The issue here is the hardcoded path introduced a week ago

[taiki-e]

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: #123151)

[rvolosatovs]

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: #123151)

indeed, LLVM strip works great for my use case, on current nightly, however, there is no way to make sure it's used other than explicitly putting the binary in /usr/bin/strip.

Will #123151 land before 1.83? I don't think #130781 should land in a release and seems that it currently targets 1.83

[jieyouxu]

#130781 cc @monkeydbobo and @davidtwco
Not sure how to solve the strip situation...

[ChrisDenton]

Not sure how to solve the strip situation...

Also check that the host is darwin too?

[Noratrieb]

how hard is it to implement "our own" (based on crates) Mach-O stripping instead of using the command? Using the strip command leads to so many problems.. (on all platforms :D)

[bjorn3]

since strip does work fine on Linux to strip Darwin binaries.

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 #130781 fixed by forcing XCode's strip to be used instead.

[rvolosatovs]

since strip does work fine on Linux to strip Darwin binaries.

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 #130781 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 strips on a x86_64-linux box directly to strip a binary compiled with cargo 1.81.0 (2dbb1af80 2024-08-20) on arm Mac and here's what I got, however:

• GNU strip: file format not recognized - the binary still works
• LLVM strip: success and stripped binary (I gave it a debug build with over 100k lines in objdump -s)

For reference:
GNU strip:

GNU strip (GNU Binutils) 2.41
Copyright (C) 2023 Free Software Foundation, Inc.
This program is free software; you may redistribute it under the terms of
the GNU General Public License version 3 or (at your option) any later version.
This program has absolutely no warranty.

LLVM strip:

llvm-strip, compatible with GNU strip
LLVM (http://llvm.org/):
  LLVM version 18.1.8
  Optimized build.

So clearly LLVM strip works just fine for stripping Mac binaries.

[bjorn3]

Ah, right. LLVM's strip should work fine.

[apiraino]

WG-prioritization assigning priority (Zulip discussion).

@rustbot label -I-prioritize +P-high

[madsmtm]

Opened #131480 to fix this directly, in case #131405 ends up taking some time.