Only dist llvm-objcopy if llvm tools are enabled

[cuviper]

This uses the same condition that #132720 added in the compilation phase.

r? @jieyouxu

[jieyouxu]

That makes sense, thanks!

[jieyouxu]

Actually just one question. @cuviper in #131405 we had to

• Includes llvm-strip (a symlink to llvm-objcopy) in the compiler dist artifact so that it can be used for -Cstrip instead of the system tooling.
• Uses llvm-strip instead of /usr/bin/strip for macOS. macOS needs a specific linker and the system one is preferred, hence Fix up setting strip = true in Cargo.toml makes build scripts fail in… #130781 but that doesn't work when cross-compiling, so use the llvm-strip utility instead.

Will changing this for the dist flow prove problematic if the dist defaults + configurations we currently use combined regress that behavior?

I think we definitely should be guarding the dist flow here, like your change does, I just wanted to double-check what our default behavior is.

[cuviper]

The default still has llvm tools enabled, so you have to explicitly opt out -- I think that's fine for the issue you mention, although it doesn't look like we have any fallback on macOS if you built without it:

rust/compiler/rustc_codegen_ssa/src/back/link.rs

Lines 1110 to 1111 in 4847d6a

	if sess.target.is_like_osx {
	let stripcmd = "rust-objcopy";

For my part, I want to opt out in Linux distro builds, and it's not used there anyway.

[jieyouxu]

Right, that sounds reasonable to me. Thanks!

@bors r+ rollup

[bors]

📌 Commit 4c6d793 has been approved by jieyouxu

It is now in the queue for this repository.

[onur-ozkan]

Nominating as it solves #135356.

@rustbot label +stable-nominated

[cuviper]

It's already on 1.85-beta, but you can still consider 1.84-stable.

@rustbot label -beta-nominated

[onur-ozkan]

@rustbot label +stable-accepted

(see Backporting #134240 to stable)