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

Fix bootstrap using host exe suffix for cargo #85590

Merged
merged 1 commit into from
May 26, 2021

Conversation

jam1garner
Copy link
Contributor

When attempting to cross compile rustc (for example, from Linux to Windows) and tell it to build cargo/tools, the following error occurs:

thread 'main' panicked at 'src.symlink_metadata() failed with No such file or directory (os error 2)', src/bootstrap/lib.rs:1196:24

Relevant part of stack trace:

   2: bootstrap::Build::copy
             at ./src/bootstrap/lib.rs:1196:24
   3: <bootstrap::tool::ToolBuild as bootstrap::builder::Step>::run
             at ./src/bootstrap/tool.rs:220:13

If I add -vvv (which seemed to be the recommended course for debugging a similar issue according to zulip logs), it shows:

Copy ".../rust/build/x86_64-unknown-linux-gnu/stage2-tools/x86_64-pc-windows-gnu/release/cargo" to ".../rust/build/x86_64-unknown-linux-gnu/stage2-tools-bin/cargo"

and when taking a look at the contents of build/x86_64-unknown-linux-gnu/stage2-tools/x86_64-pc-windows-gnu/release it contains cargo.exe, but no cargo.

I tried to study the surrounding code to make sure this was the intended behavior and while I can't be 100% certain, it does seem that using the exe suffix for the compiler.host target instead of the target target won't have the desired behavior when cross-compiling to/from Windows.

@rust-highfive
Copy link
Collaborator

Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @Mark-Simulacrum (or someone else) soon.

If any changes to this PR are deemed necessary, please add them as extra commits. This ensures that the reviewer can see what has changed since they last reviewed the code. Due to the way GitHub handles out-of-date commits, this should also make it reasonably obvious what issues have or haven't been addressed. Large or tricky changes may require several passes of review and changes.

Please see the contribution instructions for more information.

@rust-highfive rust-highfive added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label May 22, 2021
@Mark-Simulacrum
Copy link
Member

This indeed seems correct, I think.

@rust-log-analyzer

This comment has been minimized.

@jam1garner
Copy link
Contributor Author

oops, formatted

@jyn514 jyn514 changed the title Fix boostrap using host exe suffix for cargo Fix bootstrap using host exe suffix for cargo May 23, 2021
@jam1garner
Copy link
Contributor Author

@Mark-Simulacrum could I get a CI rerun when you have a moment? Thanks

@Mark-Simulacrum
Copy link
Member

@bors r+ rollup

@bors
Copy link
Contributor

bors commented May 26, 2021

📌 Commit 903e369 has been approved by Mark-Simulacrum

@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 May 26, 2021
JohnTitor added a commit to JohnTitor/rust that referenced this pull request May 26, 2021
…=Mark-Simulacrum

Fix bootstrap using host exe suffix for cargo

When attempting to cross compile rustc (for example, from Linux to Windows) and tell it to build cargo/tools, the following error occurs:

```
thread 'main' panicked at 'src.symlink_metadata() failed with No such file or directory (os error 2)', src/bootstrap/lib.rs:1196:24
```

Relevant part of stack trace:
<details>

```
   2: bootstrap::Build::copy
             at ./src/bootstrap/lib.rs:1196:24
   3: <bootstrap::tool::ToolBuild as bootstrap::builder::Step>::run
             at ./src/bootstrap/tool.rs:220:13
```
</details>

If I add `-vvv` (which seemed to be the recommended course for debugging a similar issue according to [zulip logs](https://zulip-archive.rust-lang.org/182449tcompilerhelp/19655failedtobootstrap.html)), it shows:

```
Copy ".../rust/build/x86_64-unknown-linux-gnu/stage2-tools/x86_64-pc-windows-gnu/release/cargo" to ".../rust/build/x86_64-unknown-linux-gnu/stage2-tools-bin/cargo"
```
and when taking a look at the contents of `build/x86_64-unknown-linux-gnu/stage2-tools/x86_64-pc-windows-gnu/release` it contains `cargo.exe`, but no `cargo`.

I tried to study the surrounding code to make sure this was the intended behavior and while I can't be 100% certain, it does seem that using the exe suffix for the `compiler.host` target instead of the `target` target won't have the desired behavior when cross-compiling to/from Windows.
bors added a commit to rust-lang-ci/rust that referenced this pull request May 26, 2021
Rollup of 12 pull requests

Successful merges:

 - rust-lang#84048 (Avoid CJK legacy fonts in Windows)
 - rust-lang#85529 (doc: clarify Mutex::try_lock, etc. errors)
 - rust-lang#85590 (Fix bootstrap using host exe suffix for cargo)
 - rust-lang#85610 (Fix pointer provenance in <[T]>::copy_within)
 - rust-lang#85623 (Remove stray .stderr files)
 - rust-lang#85645 (Demote `ControlFlow::{from|into}_try` to `pub(crate)`)
 - rust-lang#85647 (Revert "Move llvm submodule updates to rustbuild")
 - rust-lang#85666 (Document shared_from_cow functions)
 - rust-lang#85668 (Fix tasklist example in rustdoc book.)
 - rust-lang#85672 (Move stability attribute for items under the `ip` feature)
 - rust-lang#85699 (Update books)
 - rust-lang#85701 (Update cargo)

Failed merges:

r? `@ghost`
`@rustbot` modify labels: rollup
@bors bors merged commit d75521a into rust-lang:master May 26, 2021
@rustbot rustbot added this to the 1.54.0 milestone May 26, 2021
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.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants