FTBFS tarball rust 1.86.0: generated a symlink in a tarball: rust-lld

[rautyrauty]

Summary

The bug is not reproducible on 1.85.1.
Built from a tarball: curl -O https://static.rust-lang.org/dist/rustc-1.86.0-src.tar.gz

[00:04:41] Copy/Link "/usr/bin/lld" to "/usr/src/RPM/BUILD/rust-1.86.0/build/x86_64-unknown-linux-gnu/stage1/lib/rustlib/x86_64-unknown-linux-gnu/bin/rust-lld"
[00:22:07] thread 'main' panicked at src/bootstrap/src/utils/tarball.rs:397:21:
[00:22:07] generated a symlink in a tarball: /usr/src/RPM/BUILD/rust-1.86.0/build/tmp/tarball/rustc/x86_64-unknown-linux-gnu/rustc-1.86.0-x86_64-unknown-linux-gnu/rustc/lib/rustlib/x86_64-unknown-linux-gnu/bin/rust-lld

Command used

All commands used are listed in the build log.

Bootstrap configuration (bootstrap.toml)

I didn't create it.

Operating system

ALT Linux Sisyphus.

HEAD

Built from a tarball.

Additional context

I am building an RPM package, I am the maintainer of the rust package in ALT Linux.

[rautyrauty]

Failed to upload "rust-1.86.0-FTBFS-build.log":
https://drive.google.com/file/d/1_uxHkI2pxllOYIR0BaGTsj4wwInnKBGI/view?usp=sharing

[jieyouxu]

cc @Kobzol: I think this has to do with the lld changes?

[Kobzol]

The lld step returns a LLD binary directory here, as it assumes that it comes from download-ci-llvm. But that might not be the case, e.g. in this issue, /usr/bin/llvm-config is used as the LLVM config. The code then takes /usr/bin as the "download CI LLVM" directory, and returns the wrong (?) path. Then we try to copy /usr/bin/lld to the tarball, but that is probably not what we want, not to mention that it is likely a symlink in the OP's case.

The last PR that touched this is #134437, but I'm not sure if that change could cause this problem. I don't know if we are supposed to take the host LLD and copy it into the distributed archives as rust-lld, that sounds suspicious. I think that if we don't build the LLD, we shouldn't distribute it 🤔

[onur-ozkan]

I think that if we don't build the LLD, we shouldn't distribute it 🤔

100% agreed.

[Mark-Simulacrum]

Is that actually right? Does that break our targets that default to lld today?

It seems like distros (who often use their own upstream llvm) having an inconsistent rustc layout to what we ship isn't great if it's avoidable. In general I'd not expect lld to be special - what do we do for libLLVM? Is that distributed under an external llvm build?

Cc @cuviper

[cuviper]

In general I'd not expect lld to be special - what do we do for libLLVM? Is that distributed under an external llvm build?

That's decided in dist::maybe_install_llvm, which skips external builds.

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

Line 2099 in 990039e

fn maybe_install_llvm(

[Kobzol]

Right, thanks. I think that we should do the same for LLD, and in particular forbid combining llvm-config with rust.lld = true. It seems that this is what has been configured in this situation. #139853 should disable this combination.