Enable bootstrapping non-build-machine targets #31884
Merged
Conversation
This file contains 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
no-bootstrap-from-existing
branch
from
cef37ef to
0d7be2e
Compare
| @@ -115,6 +115,11 @@ pub fn compiler_rt(build: &Build, target: &str) { | |||
| let mode = if build.config.rust_optimize {"Release"} else {"Debug"}; | |||
| let (dir, build_target, libname) = if target.contains("linux") { | |||
| let os = if target.contains("android") {"-android"} else {""}; | |||
| let arch = if arch == "arm" && target.contains("eabihf") { | |||
There was a problem hiding this comment.
does this cover the armv7-unknown-linux-gnueabihf target?
There was a problem hiding this comment.
I... doubt it will!
|
I've tested this PR by cross compiling a compiler to arm-unknown-linux-gnueabihf. And, then testing that cross compiled rustc/std on an ARMv7 board by running some smoke tests. The smoke tests consisted of: building cargo, cargo testing hyper and cargo testing clap and all of them succeeded. (NOTE: I needed cargo on the ARM target, so I used an unofficial cargo binary from RustBuild. The host was an x86_64 machine running Ubuntu 15.10. The target was an ARMv7 machine running hard-float Ubuntu 15.10) I found two (minor) issues. @alexcrichton is already aware of them, but to reiterate:
|
This commit fixes a longstanding issue with the makefiles where all host platforms bootstrap themselves. This commit alters the build logic for the bootstrap to instead only bootstrap the build triple, and all other compilers are compiled from that one compiler. The benefit of this change is that we can cross-compile compilers which cannot run on the build platform. For example our builders could start creating `arm-unknown-linux-gnueabihf` compilers. This reduces the amount of bootstrapping we do, reducing the amount of test coverage, but overall it should largely just end in faster build times for multi-host compiles as well as enabling a feature which can't be done today. cc rust-lang#5258
These flags aren't applicable to build scripts, and may actuall wreak havoc.
Needs a different target to get built and also we apparently need to appease the C++ compiler somehow.
Currently all multi-host builds assume the the build platform can run the `llvm-config` binary generated for each host platform we're creating a compiler for. Unfortunately this assumption isn't always true when cross compiling, so we need to handle this case. This commit alters the build script of `rustc_llvm` to understand when it's running an `llvm-config` which is different than the platform we're targeting for.
Fixes `--step librustc`
Right now it's implicitly done as part of building the compiler, but this was intended to be a standalone step to ensure we tracked what built what.
This switches the defaults to ensure that everything is built with the build compiler rather than the host compiler itself (which we're not guaranteed to be able to run)
When cross compiling for a new host, we can't actually run the host compiler to generate its own libs. In theory, however, all stage2 compilers (for any host) will produce the same libraries, so we just require the build compiler to produce the necessary host libraries and then we link those into place.
These should all no longer be necessary as they've been folded into the compiler.
This allows bootstrapping new platforms immediately in stage0
Also fix a bug where we didn't clean out previous nightlies
* Fixes a warning with libc * Brings in some new flag updates for various platforms through gcc-rs * Otherwise routine updates here/there
alexcrichton
force-pushed
the
no-bootstrap-from-existing
branch
from
86d83be to
15b4a8c
Compare
|
Thanks for testing this out @japaric! I've amended the relevant commits and those issues should all be fixed. |
|
@bors r+ |
|
📌 Commit 15b4a8c has been approved by |
|
How do you exactly use this feature? Can you give an example on howto build for the ARM target you mentioned? |
Pass |
bors
added a commit
that referenced
this pull request
Feb 29, 2016
These commits add support to the rustbuild build system to compile non-build-system compilers. For example this will allow creating an ARM compiler on a x86 system. The high level way this works is: * The only compiler ever run is the build target compiler. No other compiler is assumed to be runnable. * As a result, all output artifacts come from the build compiler. * The libs for the stageN cross-compiled compiler will be linked into place after the build target builds them. This will break the assumption that a compiler never links to anything it didn't itself produce, but it retains the assumption that a compiler only ever links to anything built in the same stage. I believe this means that the stage1 cross-compiled compilers will still be usable. I tested this by creating an `arm-unknown-linux-gnueabihf` compiler. So far the linking ended up all working OK (including LLVM being cross compiled), but I haven't been able to run it yet (in QEMU for a raspberry pi). I think that's because my system linker is messed up or something like that (some newer option is assumed when it's not actually there). Overall, though, this means that rustbuild can compile an arm-unknown-linux-gnueabihf compiler. Ideally we could even start shipping nightlies based on this at some point!
48 tasks
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 add support to the rustbuild build system to compile non-build-system compilers. For example this will allow creating an ARM compiler on a x86 system. The high level way this works is:
This will break the assumption that a compiler never links to anything it didn't itself produce, but it retains the assumption that a compiler only ever links to anything built in the same stage. I believe this means that the stage1 cross-compiled compilers will still be usable.
I tested this by creating an
arm-unknown-linux-gnueabihfcompiler. So far the linking ended up all working OK (including LLVM being cross compiled), but I haven't been able to run it yet (in QEMU for a raspberry pi). I think that's because my system linker is messed up or something like that (some newer option is assumed when it's not actually there).Overall, though, this means that rustbuild can compile an arm-unknown-linux-gnueabihf compiler. Ideally we could even start shipping nightlies based on this at some point!