Fix Windows rustbuild #32206
Merged
Fix Windows rustbuild #32206
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
r? @brson |
alexcrichton
force-pushed
the
fix-windows-rustbuild
branch
from
12ef5ad to
dc38072
Compare
|
r=me with nits |
Unfortunately on i686-pc-windows-gnu LLVM's answer to `--host-target` is `x86_64-pc-windows-gnu` even though we're building in a 32-bit shell as well as compiling 32-bit libraries. For now use Cargo's `HOST` environment variable to determine whether we're doing a cross compilation or not.
This sets up the dynamic loader path for dylibs required, so should fix the MSVC build right now.
The facet of a stage is rarely relevant when running a tool or building something, it's all a question of what stage the *compiler* is built in. We've already got a nice handy `Compiler` structure to carry this information, so let's use it! This refactors the signature of the `Build::cargo` function two ways: 1. The `stage` argument is removed, this was just duplicated with the `compiler` argument's stage field. 2. The `target` argument is now required. This was a bug where if the `--target` flag isn't passed then the snapshot stage0 compiler is always used, so we won't pick up any changes. Much of the other changes in this commit are just propagating these decisions outwards. For example many of the `Step` variants no longer have a stage argument as they're baked into the compiler.
alexcrichton
force-pushed
the
fix-windows-rustbuild
branch
from
dc38072 to
158b854
Compare
| // This generally just means that we can't trust all the output of | ||
| // llvm-config becaues it might be targeted for the host rather than the | ||
| // target. | ||
| // We *want* detect this cross compiling situation by asking llvm-config |
bors
added a commit
that referenced
this pull request
Mar 15, 2016
Fix Windows rustbuild These commits fix the rustbuild Windows bots, namely: * The 32-bit build of LLVM was failing because libraries weren't being linked. This was in turn caused by the build script for `rustc_llvm` erroneously detecting that it was cross compiling when it actually wasn't. * Tools of the build were compiled against the wrong libraries, so running them would fail on Windows as rpath didn't exist and `PATH` was wrong. * Some linkchecker fixes for Windows paths had to be applied as well.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
These commits fix the rustbuild Windows bots, namely:
rustc_llvmerroneously detecting that it was cross compiling when it actually wasn't.PATHwas wrong.