Building rustc-1.84.0 tarball fails when using system LLVM

[debohman]

I have LLVM 19.1.6 installed on my system, and when building, I encounter the following:

Dist rust-std-1.84.0-x86_64-apple-darwin
	finished in 0.534 seconds
Installing stage2 std (x86_64-apple-darwin)
install: creating uninstall script at /tmp/dst.rustc/usr/local/lib/rustlib/uninstall.sh
install: installing component 'rust-std-x86_64-apple-darwin'

    rust std installed.

thread 'main' panicked at src/lib.rs:1708:24:
src.symlink_metadata() failed with No such file or directory (os error 2) ("src = /tera/tera/debo/Projects/rustc/rustc-1.84.0-src/build/x86_64-apple-darwin/stage2/lib/rustlib/x86_64-apple-darwin/bin/llvm-objcopy")
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
Build completed unsuccessfully in 0:29:14

It appears that it is trying to invoke a built copy of llvm-objcopy, when it should be using the installed version.

This is a regression.

[debohman]

The commit that is causing the build to blow up is d8ab230e731ea0bcaf299b86e82558f354f8e2b0:

commit d8ab230e731ea0bcaf299b86e82558f354f8e2b0
Author: David Wood <[email protected]>
Date:   Tue Oct 8 15:19:37 2024 +0100

    bootstrap: include `llvm-objcopy` in dist

There seems to be other work involved in this that I have not identified yet. This scheme needs to be conditional based on whether we are building and also installing the llvm tools.

Note that I have the following in my config.toml:

llvm-tools = false

[jieyouxu]

The problem is that the compiler unconditionally expects llvm-tools to be available (specifically llvm-objcopy to workaround some nasty macOS strip problems). I gated this on (1) llvm being enabled and (2) llvm-tools being enabled in #132720, but we expect this to be available in both dist and compile flows as implemented in #131405.

When you disable llvm-tools in config.toml, we probably need to require that system llvm-tools could be found and a system llvm-objcopy is copied instead, probably by querying system llvm-config.

[debohman]

Okay, but if we are not building LLVM and hence not installing the llvm-tools, then it seems to me that we should be creating a symlink from the installed llvm-objcopy to rust-objcopy for the compiler.

[onur-ozkan]

#134240 fixes that, but it's not on stable yet.

[debohman]

I made an error in my previous comment. The correct behavior is to copy the system llvm-objcopy to rust-objcopy in the destination root.

[debohman]

#134240 fixes that, but it's not on stable yet.

Yes, that will fix this problem, but you still end up with a broken toolchain due to the missing rust-objcopy.

[debohman]

% cargo build --release                                                
   Compiling sieve v0.1.0 (/tera/tera/debo/Projects/misc/sieve/rustsieve)
error: unable to run `rust-objcopy`: No such file or directory (os error 2)

error: could not compile `sieve` (bin "sieve") due to 1 previous error
% rustc --version
rustc 1.84.0

[debohman]

% sudo cp /usr/local/bin/llvm-objcopy /usr/local/bin/rust-objcopy
% cargo build --release                                          
   Compiling sieve v0.1.0 (/tera/tera/debo/Projects/misc/sieve/rustsieve)
    Finished `release` profile [optimized] target(s) in 0.60s

[onur-ozkan]

#134240 fixes that, but it's not on stable yet.

Yes, that will fix this problem, but you still end up with a broken toolchain due to the missing rust-objcopy.

Created a separate issue for that

[onur-ozkan]

I made an error in my previous comment. The correct behavior is to copy the system llvm-objcopy to rust-objcopy in the destination root.

Seems like we are already doing that

rust/src/bootstrap/src/core/build_steps/compile.rs

Lines 1765 to 1774 in 00ded39

	let llvm_bin_dir =
	command(llvm_config).arg("--bindir").run_capture_stdout(builder).stdout();
	let llvm_bin_dir = Path::new(llvm_bin_dir.trim());
	// Since we've already built the LLVM tools, install them to the sysroot.
	// This is the equivalent of installing the `llvm-tools-preview` component via
	// rustup, and lets developers use a locally built toolchain to
	// build projects that expect llvm tools to be present in the sysroot
	// (e.g. the `bootimage` crate).
	for tool in LLVM_TOOLS {

but you have to set llvm-tools=true to be able to do that.

[bryteise]

I made an error in my previous comment. The correct behavior is to copy the system llvm-objcopy to rust-objcopy in the destination root.

Seems like we are already doing that

Could this be the cause of my issue with the following?

thread 'main' panicked at src/utils/tarball.rs:397:21: generated a symlink in a tarball: /builddir/build/BUILD/rustc-1.84.0-src/build/tmp/tarball/rustc/x86_64-unknown-linux-gnu/rustc-1.84.0-x86_64-unknown-linux-gnu/rustc/lib/rustlib/x86_64-unknown-linux-gnu/bin/rust-objcopy

[onur-ozkan]

I made an error in my previous comment. The correct behavior is to copy the system llvm-objcopy to rust-objcopy in the destination root.

Seems like we are already doing that

Could this be the cause of my issue with the following?

thread 'main' panicked at src/utils/tarball.rs:397:21: generated a symlink in a tarball: /builddir/build/BUILD/rustc-1.84.0-src/build/tmp/tarball/rustc/x86_64-unknown-linux-gnu/rustc-1.84.0-x86_64-unknown-linux-gnu/rustc/lib/rustlib/x86_64-unknown-linux-gnu/bin/rust-objcopy

That seems like a different problem... Can you file an issue with more details?

[debohman]

I made an error in my previous comment. The correct behavior is to copy the system llvm-objcopy to rust-objcopy in the destination root.

Seems like we are already doing that

rust/src/bootstrap/src/core/build_steps/compile.rs

Lines 1765 to 1774 in 00ded39

let llvm_bin_dir =
command(llvm_config).arg("--bindir").run_capture_stdout(builder).stdout();
let llvm_bin_dir = Path::new(llvm_bin_dir.trim());

// Since we've already built the LLVM tools, install them to the sysroot.
// This is the equivalent of installing the llvm-tools-preview component via
// rustup, and lets developers use a locally built toolchain to
// build projects that expect llvm tools to be present in the sysroot
// (e.g. the bootimage crate).
for tool in LLVM_TOOLS {
but you have to set llvm-tools=true to be able to do that.

Isn't llvm-tools relevant only if you are building LLVM as part of rust?

[debohman]

I set llvm-tools=true and the build did not install rust-objcopy into the destination root.

[onur-ozkan]

I set llvm-tools=true and the build did not install rust-objcopy into the destination root.

#135472 (comment)

[debohman]

I can verify that setting llvm-tools=true in the configuration does install rust-objcopy into the destination root. Sorry, I was looking for it in the wrong location yesterday.

I have tested both version 1.84.0 and the current beta branch and verified that both generate operable destination roots. I did need to patch 1.84.0 with the change from #134240 in order to get it to build. I suggest that this PR covers getting #134240 into a 1.84 patch release.

[cuviper]

Should be fixed now in 1.84.1.

[debohman]

Verified in 1.84.1.