Skip to content

"x.py dist" build fails in llvm when DESTDIR is set #73132

Closed

Description

@he32

This appears to be the underlying reason for issue #71743.
When I cross-build, I have to use the "dist" x.py target to produce
a bootstrap kit, and in my setup, DESTDIR is aways set (this is in
NetBSD's packaging system, pkgsrc). I have reproduced the problem
outside the pkgsrc setup, and it is indeed a non-null DESTDIR which
triggers this issue.

Such a build errors out with

Dist RLS stage1 (x86_64-unknown-netbsd)
running: "/home/he/src/work/rust/build/x86_64-unknown-netbsd/stage0-tools-bin/fabricate" "generate" "--product-name=Rust" "--rel-manifest-dir=rustlib" "--success-message=RLS-ready-to-serve." "--image-dir" "/home/he/src/work/rust/build/tmp/dist/rls-image" "--work-dir" "/home/he/src/work/rust/build/tmp/dist" "--output-dir" "/home/he/src/work/rust/build/dist" "--non-installed-overlay" "/home/he/src/work/rust/build/tmp/dist/rls-overlay" "--package-name=rls-1.41.0-x86_64-unknown-netbsd" "--legacy-manifest-dirs=rustlib,cargo" "--component-name=rls-preview"
        finished in 15.267
  < Rls { compiler: Compiler { stage: 1, host: "x86_64-unknown-netbsd" }, target: "x86_64-unknown-netbsd" }
  > LlvmTools { target: "x86_64-unknown-netbsd" }
Dist LlvmTools (x86_64-unknown-netbsd)
thread 'main' panicked at 'Error: File "/home/he/src/work/rust/build/x86_64-unknown-netbsd/llvm/bin/llvm-nm" not found!', src/bootstrap/lib.rs:1215:17
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace.
        finished in 0.022
Traceback (most recent call last):
...

When DESTDIR is set to $(pwd)/work/destdir, llvm-nm ends up installed in
./work/destdir/home/he/src/work/rust/build/x86_64-unknown-netbsd/llvm/bin/llvm-nm
instead of what the rest of the build expects (ref. above),
./work/rust/build/x86_64-unknown-netbsd/llvm/bin/llvm-nm.
It's as if some part of the build has already figured out the full pathname to the destination,
and then proceeds to prepend $DESTDIR to that absolute path; $(pwd)
is /home/he/src/ in this setup.

The question is whether the rust build system ought to clear DESTDIR
for the build of the internal llvm, at least for the "build" phase?

The workaround I used is to unset DESTDIR for the build in total, but
doing so also for the top-level "build" target has the unfortunate side-effect that
cargo detects this change when "install" time comes, and causes everything
to be re-built. (I can see a workaround for this issue, though.)

As stated in the referenced issue, this problem is not new in 1.43, it also
exists in 1.42 and 1.41.1 -- I did not traverse further back.

The bootstrap used for the 1.41.1 build attempt was:

rustc --version --verbose:

rustc 1.40.0 (73528e339 2019-12-16)
binary: rustc
commit-hash: 73528e339aae0f17a15ffa49a8ac608f50c6cf14
commit-date: 2019-12-16
host: x86_64-unknown-netbsd
release: 1.40.0

Activity

  1. added
    T-bootstrapRelevant to the bootstrap subteam: Rust's build system (x.py and src/bootstrap)
    on Jun 8, 2020
  2. onur-ozkan commented on Dec 6, 2023

    @onur-ozkan
    Contributor

    #74252 should have fixed this already. Feel free to reopen it if otherwise.

  3. added a commit that references this issue on May 11, 2026
  4. added a commit that references this issue on May 14, 2026
  5. added a commit that references this issue on Oct 17, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    C-bugCategory: This is a bug.T-bootstrapRelevant to the bootstrap subteam: Rust's build system (x.py and src/bootstrap)

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions