Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

bootstrap: Print more debug info when find_initial_libdir fails #130138

Merged
merged 1 commit into from
Sep 14, 2024

Conversation

Zalathar
Copy link
Contributor

@Zalathar Zalathar commented Sep 9, 2024

From looking at the failure messages printed by #129775, my hypothesis is that rustc --print=sysroot sometimes prints the wrong path when the rustc executable is hardlinked in multiple places, at least on my macOS system.

However, currently I don't have any concrete evidence of this actually happening. This PR therefore expands on #129775 by printing even more information on failure (including the actual rustc path), in the hope that when the failure next occurs we can confirm or reject the hypothesis that rustc --print=sysroot is printing the wrong path.

@rustbot
Copy link
Collaborator

rustbot commented Sep 9, 2024

r? @albertlarsan68

rustbot has assigned @albertlarsan68.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

@rustbot rustbot added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. T-bootstrap Relevant to the bootstrap subteam: Rust's build system (x.py and src/bootstrap) labels Sep 9, 2024
@Zalathar
Copy link
Contributor Author

Zalathar commented Sep 9, 2024

My hypothesis is based on the following:

  • From looking at how bootstrap determines the paths involved, I can't think of any reason why it would be trying to run the stage0-sysroot compiler instead of the stage0 compiler.
  • The stage0-sysroot rustc and stage0 rustc are both hard links to the same underlying file.
  • The compiler normally uses dladdr to determine its own path (to find the corresponding sysroot).
  • https://jmmv.dev/2020/01/osxfuse-hardlinks-dladdr.html suggests that on APFS, dladdr can potentially return the “wrong” path in the presence of hard links.

This is still very speculative, which is why I'm trying to gather more information before taking action.

Copy link
Member

@albertlarsan68 albertlarsan68 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

@albertlarsan68
Copy link
Member

@bors r+ rollup

@bors
Copy link
Contributor

bors commented Sep 13, 2024

📌 Commit a21f395 has been approved by albertlarsan68

It is now in the queue for this repository.

@bors bors added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Sep 13, 2024
bors added a commit to rust-lang-ci/rust that referenced this pull request Sep 14, 2024
Rollup of 5 pull requests

Successful merges:

 - rust-lang#130138 (bootstrap: Print more debug info when `find_initial_libdir` fails)
 - rust-lang#130199 (Don't call closure_by_move_body_def_id on FnOnce async closures in MIR validation)
 - rust-lang#130302 (add llvm-bitcode-linker and llvm-tools bins to ci-rustc's sysroot)
 - rust-lang#130306 (avoid updating LLVM submodule during bootstrap unit tests)
 - rust-lang#130317 (`ProjectionElem` and `UnOp`/`BinOp` dont need to be `PartialOrd`/`Ord`)

r? `@ghost`
`@rustbot` modify labels: rollup
bors added a commit to rust-lang-ci/rust that referenced this pull request Sep 14, 2024
Rollup of 5 pull requests

Successful merges:

 - rust-lang#130138 (bootstrap: Print more debug info when `find_initial_libdir` fails)
 - rust-lang#130199 (Don't call closure_by_move_body_def_id on FnOnce async closures in MIR validation)
 - rust-lang#130302 (add llvm-bitcode-linker and llvm-tools bins to ci-rustc's sysroot)
 - rust-lang#130306 (avoid updating LLVM submodule during bootstrap unit tests)
 - rust-lang#130317 (`ProjectionElem` and `UnOp`/`BinOp` dont need to be `PartialOrd`/`Ord`)

r? `@ghost`
`@rustbot` modify labels: rollup
@bors bors merged commit 2bf0dd2 into rust-lang:master Sep 14, 2024
6 checks passed
@rustbot rustbot added this to the 1.83.0 milestone Sep 14, 2024
rust-timer added a commit to rust-lang-ci/rust that referenced this pull request Sep 14, 2024
Rollup merge of rust-lang#130138 - Zalathar:initial-libdir, r=albertlarsan68

bootstrap: Print more debug info when `find_initial_libdir` fails

From looking at the failure messages printed by rust-lang#129775, my hypothesis is that `rustc --print=sysroot` sometimes prints the wrong path when the rustc executable is hardlinked in multiple places, at least on my macOS system.

However, currently I don't have any concrete evidence of this actually happening. This PR therefore expands on rust-lang#129775 by printing even more information on failure (including the actual rustc path), in the hope that when the failure next occurs we can confirm or reject the hypothesis that `rustc --print=sysroot` is printing the wrong path.
@Zalathar Zalathar deleted the initial-libdir branch September 14, 2024 07:10
@Zalathar
Copy link
Contributor Author

Zalathar commented Oct 9, 2024

Finally witnessed this failing again on my machine:

Building bootstrap
    Finished `dev` profile [unoptimized] target(s) in 0.04s
thread 'main' panicked at src/lib.rs:348:13:
couldn't determine `initial_libdir`:
- config.initial_rustc:      "/Users/stuart/Dev/rust/rust/build/aarch64-apple-darwin/stage0/bin/rustc"
- initial_target_libdir_str: "/Users/stuart/Dev/rust/rust/build/aarch64-apple-darwin/stage0-sysroot/lib/rustlib/aarch64-apple-darwin/lib\n"
- initial_target_dir:        "/Users/stuart/Dev/rust/rust/build/aarch64-apple-darwin/stage0-sysroot/lib/rustlib/aarch64-apple-darwin"
- initial_sysroot:           "/Users/stuart/Dev/rust/rust/build/aarch64-apple-darwin/stage0"

note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
Build completed unsuccessfully in 0:00:00

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. T-bootstrap Relevant to the bootstrap subteam: Rust's build system (x.py and src/bootstrap)
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants