2015-11-19 17:20:12 -06:00
|
|
|
// Copyright 2015 The Rust Project Developers. See the COPYRIGHT
|
|
|
|
// file at the top-level directory of this distribution and at
|
|
|
|
// http://rust-lang.org/COPYRIGHT.
|
|
|
|
//
|
|
|
|
// Licensed under the Apache License, Version 2.0 <LICENSE-APACHE or
|
|
|
|
// http://www.apache.org/licenses/LICENSE-2.0> or the MIT license
|
|
|
|
// <LICENSE-MIT or http://opensource.org/licenses/MIT>, at your
|
|
|
|
// option. This file may not be copied, modified, or distributed
|
|
|
|
// except according to those terms.
|
|
|
|
|
2016-05-02 17:16:15 -05:00
|
|
|
//! Compilation of native dependencies like LLVM.
|
|
|
|
//!
|
|
|
|
//! Native projects like LLVM unfortunately aren't suited just yet for
|
2017-08-15 14:45:21 -05:00
|
|
|
//! compilation in build scripts that Cargo has. This is because the
|
2016-05-02 17:16:15 -05:00
|
|
|
//! compilation takes a *very* long time but also because we don't want to
|
|
|
|
//! compile LLVM 3 times as part of a normal bootstrap (we want it cached).
|
|
|
|
//!
|
|
|
|
//! LLVM and compiler-rt are essentially just wired up to everything else to
|
|
|
|
//! ensure that they're always in place if needed.
|
|
|
|
|
2017-03-20 16:29:14 -05:00
|
|
|
use std::env;
|
2017-02-25 11:53:46 -06:00
|
|
|
use std::ffi::OsString;
|
2016-10-07 11:43:26 -05:00
|
|
|
use std::fs::{self, File};
|
|
|
|
use std::io::{Read, Write};
|
rustc: Split Emscripten to a separate codegen backend
This commit introduces a separately compiled backend for Emscripten, avoiding
compiling the `JSBackend` target in the main LLVM codegen backend. This builds
on the foundation provided by #47671 to create a new codegen backend dedicated
solely to Emscripten, removing the `JSBackend` of the main codegen backend in
the process.
A new field was added to each target for this commit which specifies the backend
to use for translation, the default being `llvm` which is the main backend that
we use. The Emscripten targets specify an `emscripten` backend instead of the
main `llvm` one.
There's a whole bunch of consequences of this change, but I'll try to enumerate
them here:
* A *second* LLVM submodule was added in this commit. The main LLVM submodule
will soon start to drift from the Emscripten submodule, but currently they're
both at the same revision.
* Logic was added to rustbuild to *not* build the Emscripten backend by default.
This is gated behind a `--enable-emscripten` flag to the configure script. By
default users should neither check out the emscripten submodule nor compile
it.
* The `init_repo.sh` script was updated to fetch the Emscripten submodule from
GitHub the same way we do the main LLVM submodule (a tarball fetch).
* The Emscripten backend, turned off by default, is still turned on for a number
of targets on CI. We'll only be shipping an Emscripten backend with Tier 1
platforms, though. All cross-compiled platforms will not be receiving an
Emscripten backend yet.
This commit means that when you download the `rustc` package in Rustup for Tier
1 platforms you'll be receiving two trans backends, one for Emscripten and one
that's the general LLVM backend. If you never compile for Emscripten you'll
never use the Emscripten backend, so we may update this one day to only download
the Emscripten backend when you add the Emscripten target. For now though it's
just an extra 10MB gzip'd.
Closes #46819
2018-01-24 10:22:34 -06:00
|
|
|
use std::path::{Path, PathBuf};
|
2015-11-19 17:20:12 -06:00
|
|
|
use std::process::Command;
|
|
|
|
|
|
|
|
use build_helper::output;
|
|
|
|
use cmake;
|
2017-09-22 23:34:27 -05:00
|
|
|
use cc;
|
2015-11-19 17:20:12 -06:00
|
|
|
|
2016-07-05 23:58:20 -05:00
|
|
|
use Build;
|
rustc: Split Emscripten to a separate codegen backend
This commit introduces a separately compiled backend for Emscripten, avoiding
compiling the `JSBackend` target in the main LLVM codegen backend. This builds
on the foundation provided by #47671 to create a new codegen backend dedicated
solely to Emscripten, removing the `JSBackend` of the main codegen backend in
the process.
A new field was added to each target for this commit which specifies the backend
to use for translation, the default being `llvm` which is the main backend that
we use. The Emscripten targets specify an `emscripten` backend instead of the
main `llvm` one.
There's a whole bunch of consequences of this change, but I'll try to enumerate
them here:
* A *second* LLVM submodule was added in this commit. The main LLVM submodule
will soon start to drift from the Emscripten submodule, but currently they're
both at the same revision.
* Logic was added to rustbuild to *not* build the Emscripten backend by default.
This is gated behind a `--enable-emscripten` flag to the configure script. By
default users should neither check out the emscripten submodule nor compile
it.
* The `init_repo.sh` script was updated to fetch the Emscripten submodule from
GitHub the same way we do the main LLVM submodule (a tarball fetch).
* The Emscripten backend, turned off by default, is still turned on for a number
of targets on CI. We'll only be shipping an Emscripten backend with Tier 1
platforms, though. All cross-compiled platforms will not be receiving an
Emscripten backend yet.
This commit means that when you download the `rustc` package in Rustup for Tier
1 platforms you'll be receiving two trans backends, one for Emscripten and one
that's the general LLVM backend. If you never compile for Emscripten you'll
never use the Emscripten backend, so we may update this one day to only download
the Emscripten backend when you add the Emscripten target. For now though it's
just an extra 10MB gzip'd.
Closes #46819
2018-01-24 10:22:34 -06:00
|
|
|
use util::{self, exe};
|
2017-01-31 15:27:51 -06:00
|
|
|
use build_helper::up_to_date;
|
2017-07-20 18:51:07 -05:00
|
|
|
use builder::{Builder, RunConfig, ShouldRun, Step};
|
2017-07-13 19:48:44 -05:00
|
|
|
use cache::Interned;
|
2015-11-19 17:20:12 -06:00
|
|
|
|
2017-07-13 19:48:44 -05:00
|
|
|
#[derive(Debug, Copy, Clone, Hash, PartialEq, Eq)]
|
|
|
|
pub struct Llvm {
|
|
|
|
pub target: Interned<String>,
|
rustc: Split Emscripten to a separate codegen backend
This commit introduces a separately compiled backend for Emscripten, avoiding
compiling the `JSBackend` target in the main LLVM codegen backend. This builds
on the foundation provided by #47671 to create a new codegen backend dedicated
solely to Emscripten, removing the `JSBackend` of the main codegen backend in
the process.
A new field was added to each target for this commit which specifies the backend
to use for translation, the default being `llvm` which is the main backend that
we use. The Emscripten targets specify an `emscripten` backend instead of the
main `llvm` one.
There's a whole bunch of consequences of this change, but I'll try to enumerate
them here:
* A *second* LLVM submodule was added in this commit. The main LLVM submodule
will soon start to drift from the Emscripten submodule, but currently they're
both at the same revision.
* Logic was added to rustbuild to *not* build the Emscripten backend by default.
This is gated behind a `--enable-emscripten` flag to the configure script. By
default users should neither check out the emscripten submodule nor compile
it.
* The `init_repo.sh` script was updated to fetch the Emscripten submodule from
GitHub the same way we do the main LLVM submodule (a tarball fetch).
* The Emscripten backend, turned off by default, is still turned on for a number
of targets on CI. We'll only be shipping an Emscripten backend with Tier 1
platforms, though. All cross-compiled platforms will not be receiving an
Emscripten backend yet.
This commit means that when you download the `rustc` package in Rustup for Tier
1 platforms you'll be receiving two trans backends, one for Emscripten and one
that's the general LLVM backend. If you never compile for Emscripten you'll
never use the Emscripten backend, so we may update this one day to only download
the Emscripten backend when you add the Emscripten target. For now though it's
just an extra 10MB gzip'd.
Closes #46819
2018-01-24 10:22:34 -06:00
|
|
|
pub emscripten: bool,
|
2017-07-04 20:41:43 -05:00
|
|
|
}
|
|
|
|
|
2017-07-13 19:48:44 -05:00
|
|
|
impl Step for Llvm {
|
rustc: Split Emscripten to a separate codegen backend
This commit introduces a separately compiled backend for Emscripten, avoiding
compiling the `JSBackend` target in the main LLVM codegen backend. This builds
on the foundation provided by #47671 to create a new codegen backend dedicated
solely to Emscripten, removing the `JSBackend` of the main codegen backend in
the process.
A new field was added to each target for this commit which specifies the backend
to use for translation, the default being `llvm` which is the main backend that
we use. The Emscripten targets specify an `emscripten` backend instead of the
main `llvm` one.
There's a whole bunch of consequences of this change, but I'll try to enumerate
them here:
* A *second* LLVM submodule was added in this commit. The main LLVM submodule
will soon start to drift from the Emscripten submodule, but currently they're
both at the same revision.
* Logic was added to rustbuild to *not* build the Emscripten backend by default.
This is gated behind a `--enable-emscripten` flag to the configure script. By
default users should neither check out the emscripten submodule nor compile
it.
* The `init_repo.sh` script was updated to fetch the Emscripten submodule from
GitHub the same way we do the main LLVM submodule (a tarball fetch).
* The Emscripten backend, turned off by default, is still turned on for a number
of targets on CI. We'll only be shipping an Emscripten backend with Tier 1
platforms, though. All cross-compiled platforms will not be receiving an
Emscripten backend yet.
This commit means that when you download the `rustc` package in Rustup for Tier
1 platforms you'll be receiving two trans backends, one for Emscripten and one
that's the general LLVM backend. If you never compile for Emscripten you'll
never use the Emscripten backend, so we may update this one day to only download
the Emscripten backend when you add the Emscripten target. For now though it's
just an extra 10MB gzip'd.
Closes #46819
2018-01-24 10:22:34 -06:00
|
|
|
type Output = PathBuf; // path to llvm-config
|
|
|
|
|
2017-07-05 07:41:27 -05:00
|
|
|
const ONLY_HOSTS: bool = true;
|
2017-07-04 20:41:43 -05:00
|
|
|
|
2017-07-18 19:03:38 -05:00
|
|
|
fn should_run(run: ShouldRun) -> ShouldRun {
|
rustc: Split Emscripten to a separate codegen backend
This commit introduces a separately compiled backend for Emscripten, avoiding
compiling the `JSBackend` target in the main LLVM codegen backend. This builds
on the foundation provided by #47671 to create a new codegen backend dedicated
solely to Emscripten, removing the `JSBackend` of the main codegen backend in
the process.
A new field was added to each target for this commit which specifies the backend
to use for translation, the default being `llvm` which is the main backend that
we use. The Emscripten targets specify an `emscripten` backend instead of the
main `llvm` one.
There's a whole bunch of consequences of this change, but I'll try to enumerate
them here:
* A *second* LLVM submodule was added in this commit. The main LLVM submodule
will soon start to drift from the Emscripten submodule, but currently they're
both at the same revision.
* Logic was added to rustbuild to *not* build the Emscripten backend by default.
This is gated behind a `--enable-emscripten` flag to the configure script. By
default users should neither check out the emscripten submodule nor compile
it.
* The `init_repo.sh` script was updated to fetch the Emscripten submodule from
GitHub the same way we do the main LLVM submodule (a tarball fetch).
* The Emscripten backend, turned off by default, is still turned on for a number
of targets on CI. We'll only be shipping an Emscripten backend with Tier 1
platforms, though. All cross-compiled platforms will not be receiving an
Emscripten backend yet.
This commit means that when you download the `rustc` package in Rustup for Tier
1 platforms you'll be receiving two trans backends, one for Emscripten and one
that's the general LLVM backend. If you never compile for Emscripten you'll
never use the Emscripten backend, so we may update this one day to only download
the Emscripten backend when you add the Emscripten target. For now though it's
just an extra 10MB gzip'd.
Closes #46819
2018-01-24 10:22:34 -06:00
|
|
|
run.path("src/llvm").path("src/llvm-emscripten")
|
2017-07-14 07:30:16 -05:00
|
|
|
}
|
|
|
|
|
2017-07-29 15:39:43 -05:00
|
|
|
fn make_run(run: RunConfig) {
|
Change Step to be invoked with a path when in default mode.
Previously, a Step would be able to tell on its own when it was invoked
"by-default" (that is, `./x.py test` was called instead of `./x.py test
some/path`). This commit replaces that functionality, invoking each Step
with each of the paths it has specified as "should be invoked by."
For example, if a step calls `path("src/tools/cargo")` and
`path("src/doc/cargo")` then it's make_run will be called twice, with
"src/tools/cargo" and "src/doc/cargo." This makes it so that default
handling logic is in builder, instead of spread across various Steps.
However, this meant that some Step specifications needed to be updated,
since for example `rustdoc` can be built by `./x.py build
src/librustdoc` or `./x.py build src/tools/rustdoc`. A `PathSet`
abstraction is added that handles this: now, each Step can not only list
`path(...)` but also `paths(&[a, b, ...])` which will make it so that we
don't invoke it with each of the individual paths, instead invoking it
with the first path in the list (though this shouldn't be depended on).
Future work likely consists of implementing a better/easier way for a
given Step to work with "any" crate in-tree, especially those that want
to run tests, build, or check crates in the std, test, or rustc crate
trees. Currently this is rather painful to do as most of the logic is
duplicated across should_run and make_run. It seems likely this can be
abstracted away into builder somehow.
2018-02-11 10:51:58 -06:00
|
|
|
let emscripten = run.path.ends_with("llvm-emscripten");
|
rustc: Split Emscripten to a separate codegen backend
This commit introduces a separately compiled backend for Emscripten, avoiding
compiling the `JSBackend` target in the main LLVM codegen backend. This builds
on the foundation provided by #47671 to create a new codegen backend dedicated
solely to Emscripten, removing the `JSBackend` of the main codegen backend in
the process.
A new field was added to each target for this commit which specifies the backend
to use for translation, the default being `llvm` which is the main backend that
we use. The Emscripten targets specify an `emscripten` backend instead of the
main `llvm` one.
There's a whole bunch of consequences of this change, but I'll try to enumerate
them here:
* A *second* LLVM submodule was added in this commit. The main LLVM submodule
will soon start to drift from the Emscripten submodule, but currently they're
both at the same revision.
* Logic was added to rustbuild to *not* build the Emscripten backend by default.
This is gated behind a `--enable-emscripten` flag to the configure script. By
default users should neither check out the emscripten submodule nor compile
it.
* The `init_repo.sh` script was updated to fetch the Emscripten submodule from
GitHub the same way we do the main LLVM submodule (a tarball fetch).
* The Emscripten backend, turned off by default, is still turned on for a number
of targets on CI. We'll only be shipping an Emscripten backend with Tier 1
platforms, though. All cross-compiled platforms will not be receiving an
Emscripten backend yet.
This commit means that when you download the `rustc` package in Rustup for Tier
1 platforms you'll be receiving two trans backends, one for Emscripten and one
that's the general LLVM backend. If you never compile for Emscripten you'll
never use the Emscripten backend, so we may update this one day to only download
the Emscripten backend when you add the Emscripten target. For now though it's
just an extra 10MB gzip'd.
Closes #46819
2018-01-24 10:22:34 -06:00
|
|
|
run.builder.ensure(Llvm {
|
|
|
|
target: run.target,
|
|
|
|
emscripten,
|
|
|
|
});
|
2017-07-29 15:39:43 -05:00
|
|
|
}
|
|
|
|
|
2017-07-04 20:41:43 -05:00
|
|
|
/// Compile LLVM for `target`.
|
rustc: Split Emscripten to a separate codegen backend
This commit introduces a separately compiled backend for Emscripten, avoiding
compiling the `JSBackend` target in the main LLVM codegen backend. This builds
on the foundation provided by #47671 to create a new codegen backend dedicated
solely to Emscripten, removing the `JSBackend` of the main codegen backend in
the process.
A new field was added to each target for this commit which specifies the backend
to use for translation, the default being `llvm` which is the main backend that
we use. The Emscripten targets specify an `emscripten` backend instead of the
main `llvm` one.
There's a whole bunch of consequences of this change, but I'll try to enumerate
them here:
* A *second* LLVM submodule was added in this commit. The main LLVM submodule
will soon start to drift from the Emscripten submodule, but currently they're
both at the same revision.
* Logic was added to rustbuild to *not* build the Emscripten backend by default.
This is gated behind a `--enable-emscripten` flag to the configure script. By
default users should neither check out the emscripten submodule nor compile
it.
* The `init_repo.sh` script was updated to fetch the Emscripten submodule from
GitHub the same way we do the main LLVM submodule (a tarball fetch).
* The Emscripten backend, turned off by default, is still turned on for a number
of targets on CI. We'll only be shipping an Emscripten backend with Tier 1
platforms, though. All cross-compiled platforms will not be receiving an
Emscripten backend yet.
This commit means that when you download the `rustc` package in Rustup for Tier
1 platforms you'll be receiving two trans backends, one for Emscripten and one
that's the general LLVM backend. If you never compile for Emscripten you'll
never use the Emscripten backend, so we may update this one day to only download
the Emscripten backend when you add the Emscripten target. For now though it's
just an extra 10MB gzip'd.
Closes #46819
2018-01-24 10:22:34 -06:00
|
|
|
fn run(self, builder: &Builder) -> PathBuf {
|
2017-07-04 20:41:43 -05:00
|
|
|
let build = builder.build;
|
|
|
|
let target = self.target;
|
rustc: Split Emscripten to a separate codegen backend
This commit introduces a separately compiled backend for Emscripten, avoiding
compiling the `JSBackend` target in the main LLVM codegen backend. This builds
on the foundation provided by #47671 to create a new codegen backend dedicated
solely to Emscripten, removing the `JSBackend` of the main codegen backend in
the process.
A new field was added to each target for this commit which specifies the backend
to use for translation, the default being `llvm` which is the main backend that
we use. The Emscripten targets specify an `emscripten` backend instead of the
main `llvm` one.
There's a whole bunch of consequences of this change, but I'll try to enumerate
them here:
* A *second* LLVM submodule was added in this commit. The main LLVM submodule
will soon start to drift from the Emscripten submodule, but currently they're
both at the same revision.
* Logic was added to rustbuild to *not* build the Emscripten backend by default.
This is gated behind a `--enable-emscripten` flag to the configure script. By
default users should neither check out the emscripten submodule nor compile
it.
* The `init_repo.sh` script was updated to fetch the Emscripten submodule from
GitHub the same way we do the main LLVM submodule (a tarball fetch).
* The Emscripten backend, turned off by default, is still turned on for a number
of targets on CI. We'll only be shipping an Emscripten backend with Tier 1
platforms, though. All cross-compiled platforms will not be receiving an
Emscripten backend yet.
This commit means that when you download the `rustc` package in Rustup for Tier
1 platforms you'll be receiving two trans backends, one for Emscripten and one
that's the general LLVM backend. If you never compile for Emscripten you'll
never use the Emscripten backend, so we may update this one day to only download
the Emscripten backend when you add the Emscripten target. For now though it's
just an extra 10MB gzip'd.
Closes #46819
2018-01-24 10:22:34 -06:00
|
|
|
let emscripten = self.emscripten;
|
2017-06-18 09:00:10 -05:00
|
|
|
|
2017-07-04 20:41:43 -05:00
|
|
|
// If we're using a custom LLVM bail out here, but we can only use a
|
|
|
|
// custom LLVM for the build triple.
|
rustc: Split Emscripten to a separate codegen backend
This commit introduces a separately compiled backend for Emscripten, avoiding
compiling the `JSBackend` target in the main LLVM codegen backend. This builds
on the foundation provided by #47671 to create a new codegen backend dedicated
solely to Emscripten, removing the `JSBackend` of the main codegen backend in
the process.
A new field was added to each target for this commit which specifies the backend
to use for translation, the default being `llvm` which is the main backend that
we use. The Emscripten targets specify an `emscripten` backend instead of the
main `llvm` one.
There's a whole bunch of consequences of this change, but I'll try to enumerate
them here:
* A *second* LLVM submodule was added in this commit. The main LLVM submodule
will soon start to drift from the Emscripten submodule, but currently they're
both at the same revision.
* Logic was added to rustbuild to *not* build the Emscripten backend by default.
This is gated behind a `--enable-emscripten` flag to the configure script. By
default users should neither check out the emscripten submodule nor compile
it.
* The `init_repo.sh` script was updated to fetch the Emscripten submodule from
GitHub the same way we do the main LLVM submodule (a tarball fetch).
* The Emscripten backend, turned off by default, is still turned on for a number
of targets on CI. We'll only be shipping an Emscripten backend with Tier 1
platforms, though. All cross-compiled platforms will not be receiving an
Emscripten backend yet.
This commit means that when you download the `rustc` package in Rustup for Tier
1 platforms you'll be receiving two trans backends, one for Emscripten and one
that's the general LLVM backend. If you never compile for Emscripten you'll
never use the Emscripten backend, so we may update this one day to only download
the Emscripten backend when you add the Emscripten target. For now though it's
just an extra 10MB gzip'd.
Closes #46819
2018-01-24 10:22:34 -06:00
|
|
|
if !self.emscripten {
|
|
|
|
if let Some(config) = build.config.target_config.get(&target) {
|
|
|
|
if let Some(ref s) = config.llvm_config {
|
|
|
|
check_llvm_version(build, s);
|
|
|
|
return s.to_path_buf()
|
|
|
|
}
|
2017-07-04 20:41:43 -05:00
|
|
|
}
|
2015-11-19 17:20:12 -06:00
|
|
|
}
|
|
|
|
|
2017-07-04 20:41:43 -05:00
|
|
|
let rebuild_trigger = build.src.join("src/rustllvm/llvm-rebuild-trigger");
|
|
|
|
let mut rebuild_trigger_contents = String::new();
|
|
|
|
t!(t!(File::open(&rebuild_trigger)).read_to_string(&mut rebuild_trigger_contents));
|
2017-03-03 08:18:44 -06:00
|
|
|
|
rustc: Split Emscripten to a separate codegen backend
This commit introduces a separately compiled backend for Emscripten, avoiding
compiling the `JSBackend` target in the main LLVM codegen backend. This builds
on the foundation provided by #47671 to create a new codegen backend dedicated
solely to Emscripten, removing the `JSBackend` of the main codegen backend in
the process.
A new field was added to each target for this commit which specifies the backend
to use for translation, the default being `llvm` which is the main backend that
we use. The Emscripten targets specify an `emscripten` backend instead of the
main `llvm` one.
There's a whole bunch of consequences of this change, but I'll try to enumerate
them here:
* A *second* LLVM submodule was added in this commit. The main LLVM submodule
will soon start to drift from the Emscripten submodule, but currently they're
both at the same revision.
* Logic was added to rustbuild to *not* build the Emscripten backend by default.
This is gated behind a `--enable-emscripten` flag to the configure script. By
default users should neither check out the emscripten submodule nor compile
it.
* The `init_repo.sh` script was updated to fetch the Emscripten submodule from
GitHub the same way we do the main LLVM submodule (a tarball fetch).
* The Emscripten backend, turned off by default, is still turned on for a number
of targets on CI. We'll only be shipping an Emscripten backend with Tier 1
platforms, though. All cross-compiled platforms will not be receiving an
Emscripten backend yet.
This commit means that when you download the `rustc` package in Rustup for Tier
1 platforms you'll be receiving two trans backends, one for Emscripten and one
that's the general LLVM backend. If you never compile for Emscripten you'll
never use the Emscripten backend, so we may update this one day to only download
the Emscripten backend when you add the Emscripten target. For now though it's
just an extra 10MB gzip'd.
Closes #46819
2018-01-24 10:22:34 -06:00
|
|
|
let (out_dir, llvm_config_ret_dir) = if emscripten {
|
|
|
|
let dir = build.emscripten_llvm_out(target);
|
2018-03-05 11:47:54 -06:00
|
|
|
let config_dir = dir.join("bin");
|
rustc: Split Emscripten to a separate codegen backend
This commit introduces a separately compiled backend for Emscripten, avoiding
compiling the `JSBackend` target in the main LLVM codegen backend. This builds
on the foundation provided by #47671 to create a new codegen backend dedicated
solely to Emscripten, removing the `JSBackend` of the main codegen backend in
the process.
A new field was added to each target for this commit which specifies the backend
to use for translation, the default being `llvm` which is the main backend that
we use. The Emscripten targets specify an `emscripten` backend instead of the
main `llvm` one.
There's a whole bunch of consequences of this change, but I'll try to enumerate
them here:
* A *second* LLVM submodule was added in this commit. The main LLVM submodule
will soon start to drift from the Emscripten submodule, but currently they're
both at the same revision.
* Logic was added to rustbuild to *not* build the Emscripten backend by default.
This is gated behind a `--enable-emscripten` flag to the configure script. By
default users should neither check out the emscripten submodule nor compile
it.
* The `init_repo.sh` script was updated to fetch the Emscripten submodule from
GitHub the same way we do the main LLVM submodule (a tarball fetch).
* The Emscripten backend, turned off by default, is still turned on for a number
of targets on CI. We'll only be shipping an Emscripten backend with Tier 1
platforms, though. All cross-compiled platforms will not be receiving an
Emscripten backend yet.
This commit means that when you download the `rustc` package in Rustup for Tier
1 platforms you'll be receiving two trans backends, one for Emscripten and one
that's the general LLVM backend. If you never compile for Emscripten you'll
never use the Emscripten backend, so we may update this one day to only download
the Emscripten backend when you add the Emscripten target. For now though it's
just an extra 10MB gzip'd.
Closes #46819
2018-01-24 10:22:34 -06:00
|
|
|
(dir, config_dir)
|
|
|
|
} else {
|
2018-03-05 11:47:54 -06:00
|
|
|
let mut dir = build.llvm_out(build.config.build);
|
|
|
|
if !build.config.build.contains("msvc") || build.config.ninja {
|
|
|
|
dir.push("build");
|
|
|
|
}
|
|
|
|
(build.llvm_out(target), dir.join("bin"))
|
rustc: Split Emscripten to a separate codegen backend
This commit introduces a separately compiled backend for Emscripten, avoiding
compiling the `JSBackend` target in the main LLVM codegen backend. This builds
on the foundation provided by #47671 to create a new codegen backend dedicated
solely to Emscripten, removing the `JSBackend` of the main codegen backend in
the process.
A new field was added to each target for this commit which specifies the backend
to use for translation, the default being `llvm` which is the main backend that
we use. The Emscripten targets specify an `emscripten` backend instead of the
main `llvm` one.
There's a whole bunch of consequences of this change, but I'll try to enumerate
them here:
* A *second* LLVM submodule was added in this commit. The main LLVM submodule
will soon start to drift from the Emscripten submodule, but currently they're
both at the same revision.
* Logic was added to rustbuild to *not* build the Emscripten backend by default.
This is gated behind a `--enable-emscripten` flag to the configure script. By
default users should neither check out the emscripten submodule nor compile
it.
* The `init_repo.sh` script was updated to fetch the Emscripten submodule from
GitHub the same way we do the main LLVM submodule (a tarball fetch).
* The Emscripten backend, turned off by default, is still turned on for a number
of targets on CI. We'll only be shipping an Emscripten backend with Tier 1
platforms, though. All cross-compiled platforms will not be receiving an
Emscripten backend yet.
This commit means that when you download the `rustc` package in Rustup for Tier
1 platforms you'll be receiving two trans backends, one for Emscripten and one
that's the general LLVM backend. If you never compile for Emscripten you'll
never use the Emscripten backend, so we may update this one day to only download
the Emscripten backend when you add the Emscripten target. For now though it's
just an extra 10MB gzip'd.
Closes #46819
2018-01-24 10:22:34 -06:00
|
|
|
};
|
2017-07-04 20:41:43 -05:00
|
|
|
let done_stamp = out_dir.join("llvm-finished-building");
|
rustc: Split Emscripten to a separate codegen backend
This commit introduces a separately compiled backend for Emscripten, avoiding
compiling the `JSBackend` target in the main LLVM codegen backend. This builds
on the foundation provided by #47671 to create a new codegen backend dedicated
solely to Emscripten, removing the `JSBackend` of the main codegen backend in
the process.
A new field was added to each target for this commit which specifies the backend
to use for translation, the default being `llvm` which is the main backend that
we use. The Emscripten targets specify an `emscripten` backend instead of the
main `llvm` one.
There's a whole bunch of consequences of this change, but I'll try to enumerate
them here:
* A *second* LLVM submodule was added in this commit. The main LLVM submodule
will soon start to drift from the Emscripten submodule, but currently they're
both at the same revision.
* Logic was added to rustbuild to *not* build the Emscripten backend by default.
This is gated behind a `--enable-emscripten` flag to the configure script. By
default users should neither check out the emscripten submodule nor compile
it.
* The `init_repo.sh` script was updated to fetch the Emscripten submodule from
GitHub the same way we do the main LLVM submodule (a tarball fetch).
* The Emscripten backend, turned off by default, is still turned on for a number
of targets on CI. We'll only be shipping an Emscripten backend with Tier 1
platforms, though. All cross-compiled platforms will not be receiving an
Emscripten backend yet.
This commit means that when you download the `rustc` package in Rustup for Tier
1 platforms you'll be receiving two trans backends, one for Emscripten and one
that's the general LLVM backend. If you never compile for Emscripten you'll
never use the Emscripten backend, so we may update this one day to only download
the Emscripten backend when you add the Emscripten target. For now though it's
just an extra 10MB gzip'd.
Closes #46819
2018-01-24 10:22:34 -06:00
|
|
|
let build_llvm_config = llvm_config_ret_dir
|
|
|
|
.join(exe("llvm-config", &*build.config.build));
|
2017-07-04 20:41:43 -05:00
|
|
|
if done_stamp.exists() {
|
|
|
|
let mut done_contents = String::new();
|
|
|
|
t!(t!(File::open(&done_stamp)).read_to_string(&mut done_contents));
|
2017-03-03 08:18:44 -06:00
|
|
|
|
2017-07-04 20:41:43 -05:00
|
|
|
// If LLVM was already built previously and contents of the rebuild-trigger file
|
|
|
|
// didn't change from the previous build, then no action is required.
|
|
|
|
if done_contents == rebuild_trigger_contents {
|
rustc: Split Emscripten to a separate codegen backend
This commit introduces a separately compiled backend for Emscripten, avoiding
compiling the `JSBackend` target in the main LLVM codegen backend. This builds
on the foundation provided by #47671 to create a new codegen backend dedicated
solely to Emscripten, removing the `JSBackend` of the main codegen backend in
the process.
A new field was added to each target for this commit which specifies the backend
to use for translation, the default being `llvm` which is the main backend that
we use. The Emscripten targets specify an `emscripten` backend instead of the
main `llvm` one.
There's a whole bunch of consequences of this change, but I'll try to enumerate
them here:
* A *second* LLVM submodule was added in this commit. The main LLVM submodule
will soon start to drift from the Emscripten submodule, but currently they're
both at the same revision.
* Logic was added to rustbuild to *not* build the Emscripten backend by default.
This is gated behind a `--enable-emscripten` flag to the configure script. By
default users should neither check out the emscripten submodule nor compile
it.
* The `init_repo.sh` script was updated to fetch the Emscripten submodule from
GitHub the same way we do the main LLVM submodule (a tarball fetch).
* The Emscripten backend, turned off by default, is still turned on for a number
of targets on CI. We'll only be shipping an Emscripten backend with Tier 1
platforms, though. All cross-compiled platforms will not be receiving an
Emscripten backend yet.
This commit means that when you download the `rustc` package in Rustup for Tier
1 platforms you'll be receiving two trans backends, one for Emscripten and one
that's the general LLVM backend. If you never compile for Emscripten you'll
never use the Emscripten backend, so we may update this one day to only download
the Emscripten backend when you add the Emscripten target. For now though it's
just an extra 10MB gzip'd.
Closes #46819
2018-01-24 10:22:34 -06:00
|
|
|
return build_llvm_config
|
2017-07-04 20:41:43 -05:00
|
|
|
}
|
|
|
|
}
|
2015-11-19 17:20:12 -06:00
|
|
|
|
2017-07-04 20:41:43 -05:00
|
|
|
let _folder = build.fold_output(|| "llvm");
|
rustc: Split Emscripten to a separate codegen backend
This commit introduces a separately compiled backend for Emscripten, avoiding
compiling the `JSBackend` target in the main LLVM codegen backend. This builds
on the foundation provided by #47671 to create a new codegen backend dedicated
solely to Emscripten, removing the `JSBackend` of the main codegen backend in
the process.
A new field was added to each target for this commit which specifies the backend
to use for translation, the default being `llvm` which is the main backend that
we use. The Emscripten targets specify an `emscripten` backend instead of the
main `llvm` one.
There's a whole bunch of consequences of this change, but I'll try to enumerate
them here:
* A *second* LLVM submodule was added in this commit. The main LLVM submodule
will soon start to drift from the Emscripten submodule, but currently they're
both at the same revision.
* Logic was added to rustbuild to *not* build the Emscripten backend by default.
This is gated behind a `--enable-emscripten` flag to the configure script. By
default users should neither check out the emscripten submodule nor compile
it.
* The `init_repo.sh` script was updated to fetch the Emscripten submodule from
GitHub the same way we do the main LLVM submodule (a tarball fetch).
* The Emscripten backend, turned off by default, is still turned on for a number
of targets on CI. We'll only be shipping an Emscripten backend with Tier 1
platforms, though. All cross-compiled platforms will not be receiving an
Emscripten backend yet.
This commit means that when you download the `rustc` package in Rustup for Tier
1 platforms you'll be receiving two trans backends, one for Emscripten and one
that's the general LLVM backend. If you never compile for Emscripten you'll
never use the Emscripten backend, so we may update this one day to only download
the Emscripten backend when you add the Emscripten target. For now though it's
just an extra 10MB gzip'd.
Closes #46819
2018-01-24 10:22:34 -06:00
|
|
|
let descriptor = if emscripten { "Emscripten " } else { "" };
|
|
|
|
println!("Building {}LLVM for {}", descriptor, target);
|
2017-07-04 20:41:43 -05:00
|
|
|
let _time = util::timeit();
|
|
|
|
t!(fs::create_dir_all(&out_dir));
|
2015-11-19 17:20:12 -06:00
|
|
|
|
2017-07-04 20:41:43 -05:00
|
|
|
// http://llvm.org/docs/CMake.html
|
rustc: Split Emscripten to a separate codegen backend
This commit introduces a separately compiled backend for Emscripten, avoiding
compiling the `JSBackend` target in the main LLVM codegen backend. This builds
on the foundation provided by #47671 to create a new codegen backend dedicated
solely to Emscripten, removing the `JSBackend` of the main codegen backend in
the process.
A new field was added to each target for this commit which specifies the backend
to use for translation, the default being `llvm` which is the main backend that
we use. The Emscripten targets specify an `emscripten` backend instead of the
main `llvm` one.
There's a whole bunch of consequences of this change, but I'll try to enumerate
them here:
* A *second* LLVM submodule was added in this commit. The main LLVM submodule
will soon start to drift from the Emscripten submodule, but currently they're
both at the same revision.
* Logic was added to rustbuild to *not* build the Emscripten backend by default.
This is gated behind a `--enable-emscripten` flag to the configure script. By
default users should neither check out the emscripten submodule nor compile
it.
* The `init_repo.sh` script was updated to fetch the Emscripten submodule from
GitHub the same way we do the main LLVM submodule (a tarball fetch).
* The Emscripten backend, turned off by default, is still turned on for a number
of targets on CI. We'll only be shipping an Emscripten backend with Tier 1
platforms, though. All cross-compiled platforms will not be receiving an
Emscripten backend yet.
This commit means that when you download the `rustc` package in Rustup for Tier
1 platforms you'll be receiving two trans backends, one for Emscripten and one
that's the general LLVM backend. If you never compile for Emscripten you'll
never use the Emscripten backend, so we may update this one day to only download
the Emscripten backend when you add the Emscripten target. For now though it's
just an extra 10MB gzip'd.
Closes #46819
2018-01-24 10:22:34 -06:00
|
|
|
let root = if self.emscripten { "src/llvm-emscripten" } else { "src/llvm" };
|
|
|
|
let mut cfg = cmake::Config::new(build.src.join(root));
|
2016-11-10 10:30:06 -06:00
|
|
|
|
2017-07-04 20:41:43 -05:00
|
|
|
let profile = match (build.config.llvm_optimize, build.config.llvm_release_debuginfo) {
|
|
|
|
(false, _) => "Debug",
|
|
|
|
(true, false) => "Release",
|
|
|
|
(true, true) => "RelWithDebInfo",
|
|
|
|
};
|
2017-02-14 16:30:39 -06:00
|
|
|
|
rustc: Split Emscripten to a separate codegen backend
This commit introduces a separately compiled backend for Emscripten, avoiding
compiling the `JSBackend` target in the main LLVM codegen backend. This builds
on the foundation provided by #47671 to create a new codegen backend dedicated
solely to Emscripten, removing the `JSBackend` of the main codegen backend in
the process.
A new field was added to each target for this commit which specifies the backend
to use for translation, the default being `llvm` which is the main backend that
we use. The Emscripten targets specify an `emscripten` backend instead of the
main `llvm` one.
There's a whole bunch of consequences of this change, but I'll try to enumerate
them here:
* A *second* LLVM submodule was added in this commit. The main LLVM submodule
will soon start to drift from the Emscripten submodule, but currently they're
both at the same revision.
* Logic was added to rustbuild to *not* build the Emscripten backend by default.
This is gated behind a `--enable-emscripten` flag to the configure script. By
default users should neither check out the emscripten submodule nor compile
it.
* The `init_repo.sh` script was updated to fetch the Emscripten submodule from
GitHub the same way we do the main LLVM submodule (a tarball fetch).
* The Emscripten backend, turned off by default, is still turned on for a number
of targets on CI. We'll only be shipping an Emscripten backend with Tier 1
platforms, though. All cross-compiled platforms will not be receiving an
Emscripten backend yet.
This commit means that when you download the `rustc` package in Rustup for Tier
1 platforms you'll be receiving two trans backends, one for Emscripten and one
that's the general LLVM backend. If you never compile for Emscripten you'll
never use the Emscripten backend, so we may update this one day to only download
the Emscripten backend when you add the Emscripten target. For now though it's
just an extra 10MB gzip'd.
Closes #46819
2018-01-24 10:22:34 -06:00
|
|
|
// NOTE: remember to also update `config.toml.example` when changing the
|
|
|
|
// defaults!
|
|
|
|
let llvm_targets = if self.emscripten {
|
|
|
|
"JSBackend"
|
|
|
|
} else {
|
|
|
|
match build.config.llvm_targets {
|
|
|
|
Some(ref s) => s,
|
|
|
|
None => "X86;ARM;AArch64;Mips;PowerPC;SystemZ;MSP430;Sparc;NVPTX;Hexagon",
|
|
|
|
}
|
2017-07-04 20:41:43 -05:00
|
|
|
};
|
2015-11-19 17:20:12 -06:00
|
|
|
|
rustc: Split Emscripten to a separate codegen backend
This commit introduces a separately compiled backend for Emscripten, avoiding
compiling the `JSBackend` target in the main LLVM codegen backend. This builds
on the foundation provided by #47671 to create a new codegen backend dedicated
solely to Emscripten, removing the `JSBackend` of the main codegen backend in
the process.
A new field was added to each target for this commit which specifies the backend
to use for translation, the default being `llvm` which is the main backend that
we use. The Emscripten targets specify an `emscripten` backend instead of the
main `llvm` one.
There's a whole bunch of consequences of this change, but I'll try to enumerate
them here:
* A *second* LLVM submodule was added in this commit. The main LLVM submodule
will soon start to drift from the Emscripten submodule, but currently they're
both at the same revision.
* Logic was added to rustbuild to *not* build the Emscripten backend by default.
This is gated behind a `--enable-emscripten` flag to the configure script. By
default users should neither check out the emscripten submodule nor compile
it.
* The `init_repo.sh` script was updated to fetch the Emscripten submodule from
GitHub the same way we do the main LLVM submodule (a tarball fetch).
* The Emscripten backend, turned off by default, is still turned on for a number
of targets on CI. We'll only be shipping an Emscripten backend with Tier 1
platforms, though. All cross-compiled platforms will not be receiving an
Emscripten backend yet.
This commit means that when you download the `rustc` package in Rustup for Tier
1 platforms you'll be receiving two trans backends, one for Emscripten and one
that's the general LLVM backend. If you never compile for Emscripten you'll
never use the Emscripten backend, so we may update this one day to only download
the Emscripten backend when you add the Emscripten target. For now though it's
just an extra 10MB gzip'd.
Closes #46819
2018-01-24 10:22:34 -06:00
|
|
|
let llvm_exp_targets = if self.emscripten {
|
|
|
|
""
|
|
|
|
} else {
|
|
|
|
&build.config.llvm_experimental_targets[..]
|
|
|
|
};
|
2017-03-05 09:11:11 -06:00
|
|
|
|
2017-07-04 20:41:43 -05:00
|
|
|
let assertions = if build.config.llvm_assertions {"ON"} else {"OFF"};
|
|
|
|
|
rust: Import LLD for linking wasm objects
This commit imports the LLD project from LLVM to serve as the default linker for
the `wasm32-unknown-unknown` target. The `binaryen` submoule is consequently
removed along with "binaryen linker" support in rustc.
Moving to LLD brings with it a number of benefits for wasm code:
* LLD is itself an actual linker, so there's no need to compile all wasm code
with LTO any more. As a result builds should be *much* speedier as LTO is no
longer forcibly enabled for all builds of the wasm target.
* LLD is quickly becoming an "official solution" for linking wasm code together.
This, I believe at least, is intended to be the main supported linker for
native code and wasm moving forward. Picking up support early on should help
ensure that we can help LLD identify bugs and otherwise prove that it works
great for all our use cases!
* Improvements to the wasm toolchain are currently primarily focused around LLVM
and LLD (from what I can tell at least), so it's in general much better to be
on this bandwagon for bugfixes and new features.
* Historical "hacks" like `wasm-gc` will soon no longer be necessary, LLD
will [natively implement][gc] `--gc-sections` (better than `wasm-gc`!) which
means a postprocessor is no longer needed to show off Rust's "small wasm
binary size".
LLD is added in a pretty standard way to rustc right now. A new rustbuild target
was defined for building LLD, and this is executed when a compiler's sysroot is
being assembled. LLD is compiled against the LLVM that we've got in tree, which
means we're currently on the `release_60` branch, but this may get upgraded in
the near future!
LLD is placed into rustc's sysroot in a `bin` directory. This is similar to
where `gcc.exe` can be found on Windows. This directory is automatically added
to `PATH` whenever rustc executes the linker, allowing us to define a `WasmLd`
linker which implements the interface that `wasm-ld`, LLD's frontend, expects.
Like Emscripten the LLD target is currently only enabled for Tier 1 platforms,
notably OSX/Windows/Linux, and will need to be installed manually for compiling
to wasm on other platforms. LLD is by default turned off in rustbuild, and
requires a `config.toml` option to be enabled to turn it on.
Finally the unstable `#![wasm_import_memory]` attribute was also removed as LLD
has a native option for controlling this.
[gc]: https://reviews.llvm.org/D42511
2017-08-26 20:30:12 -05:00
|
|
|
cfg.out_dir(&out_dir)
|
2017-07-04 20:41:43 -05:00
|
|
|
.profile(profile)
|
|
|
|
.define("LLVM_ENABLE_ASSERTIONS", assertions)
|
|
|
|
.define("LLVM_TARGETS_TO_BUILD", llvm_targets)
|
|
|
|
.define("LLVM_EXPERIMENTAL_TARGETS_TO_BUILD", llvm_exp_targets)
|
|
|
|
.define("LLVM_INCLUDE_EXAMPLES", "OFF")
|
|
|
|
.define("LLVM_INCLUDE_TESTS", "OFF")
|
|
|
|
.define("LLVM_INCLUDE_DOCS", "OFF")
|
|
|
|
.define("LLVM_ENABLE_ZLIB", "OFF")
|
|
|
|
.define("WITH_POLLY", "OFF")
|
|
|
|
.define("LLVM_ENABLE_TERMINFO", "OFF")
|
|
|
|
.define("LLVM_ENABLE_LIBEDIT", "OFF")
|
|
|
|
.define("LLVM_PARALLEL_COMPILE_JOBS", build.jobs().to_string())
|
|
|
|
.define("LLVM_TARGET_ARCH", target.split('-').next().unwrap())
|
|
|
|
.define("LLVM_DEFAULT_TARGET_TRIPLE", target);
|
2015-11-19 17:20:12 -06:00
|
|
|
|
2018-02-10 14:29:10 -06:00
|
|
|
// By default, LLVM will automatically find OCaml and, if it finds it,
|
|
|
|
// install the LLVM bindings in LLVM_OCAML_INSTALL_PATH, which defaults
|
|
|
|
// to /usr/bin/ocaml.
|
|
|
|
// This causes problem for non-root builds of Rust. Side-step the issue
|
|
|
|
// by setting LLVM_OCAML_INSTALL_PATH to a relative path, so it installs
|
|
|
|
// in the prefix.
|
|
|
|
cfg.define("LLVM_OCAML_INSTALL_PATH",
|
|
|
|
env::var_os("LLVM_OCAML_INSTALL_PATH").unwrap_or_else(|| "usr/lib/ocaml".into()));
|
2017-08-03 17:42:05 -05:00
|
|
|
|
|
|
|
// This setting makes the LLVM tools link to the dynamic LLVM library,
|
|
|
|
// which saves both memory during parallel links and overall disk space
|
|
|
|
// for the tools. We don't distribute any of those tools, so this is
|
2017-08-04 02:13:11 -05:00
|
|
|
// just a local concern. However, it doesn't work well everywhere.
|
|
|
|
if target.contains("linux-gnu") || target.contains("apple-darwin") {
|
2017-08-03 17:42:05 -05:00
|
|
|
cfg.define("LLVM_LINK_LLVM_DYLIB", "ON");
|
|
|
|
}
|
|
|
|
|
2017-02-25 11:53:46 -06:00
|
|
|
if target.contains("msvc") {
|
2017-07-04 20:41:43 -05:00
|
|
|
cfg.define("LLVM_USE_CRT_DEBUG", "MT");
|
|
|
|
cfg.define("LLVM_USE_CRT_RELEASE", "MT");
|
|
|
|
cfg.define("LLVM_USE_CRT_RELWITHDEBINFO", "MT");
|
|
|
|
cfg.static_crt(true);
|
2017-02-25 11:53:46 -06:00
|
|
|
}
|
|
|
|
|
2017-07-04 20:41:43 -05:00
|
|
|
if target.starts_with("i686") {
|
|
|
|
cfg.define("LLVM_BUILD_32_BITS", "ON");
|
2017-02-25 11:53:46 -06:00
|
|
|
}
|
|
|
|
|
2017-07-04 20:41:43 -05:00
|
|
|
if let Some(num_linkers) = build.config.llvm_link_jobs {
|
|
|
|
if num_linkers > 0 {
|
|
|
|
cfg.define("LLVM_PARALLEL_LINK_JOBS", num_linkers.to_string());
|
|
|
|
}
|
2015-11-19 17:20:12 -06:00
|
|
|
}
|
2016-03-29 23:51:00 -05:00
|
|
|
|
2017-07-04 20:41:43 -05:00
|
|
|
// http://llvm.org/docs/HowToCrossCompileLLVM.html
|
rustc: Upgrade to LLVM 6
The following submodules have been updated for a new version of LLVM:
- `src/llvm`
- `src/libcompiler_builtins` - transitively contains compiler-rt
- `src/dlmalloc`
This also updates the docker container for dist-i686-freebsd as the old 16.04
container is no longer capable of building LLVM. The
compiler-rt/compiler-builtins and dlmalloc updates are pretty routine without
much interesting happening, but the LLVM update here is of particular note.
Unlike previous updates I haven't cherry-picked all existing patches we had on
top of our LLVM branch as we have a [huge amount][patches4] and have at this
point forgotten what most of them are for. Instead I started from the current
`release_60` branch in LLVM and only applied patches that were necessary to get
our tests working and building.
The current set of custom rustc-specific patches included in this LLVM update are:
* rust-lang/llvm@1187443 - this is how we actually implement
`cfg(target_feature)` for now and continues to not be upstreamed. While a
hazard for SIMD stabilization this commit is otherwise keeping the status
quo of a small rustc-specific feature.
* rust-lang/llvm@013f2ec - this is a rustc-specific optimization that we haven't
upstreamed, notably teaching LLVM about our allocation-related routines (which
aren't malloc/free). Once we stabilize the global allocator routines we will
likely want to upstream this patch, but for now it seems reasonable to keep it
on our fork.
* rust-lang/llvm@a65bbfd - I found this necessary to fix compilation of LLVM in
our 32-bit linux container. I'm not really sure why it's necessary but my
guess is that it's because of the absolutely ancient glibc that we're using.
In any case it's only updating pieces we're not actually using in LLVM so I'm
hoping it'll turn out alright. This doesn't seem like something we'll want to
upstream.c
* rust-lang/llvm@77ab1f0 - this is what's actually enabling LLVM to build in our
i686-freebsd container, I'm not really sure what's going on but we for sure
probably don't want to upstream this and otherwise it seems not too bad for
now at least.
* rust-lang/llvm@9eb9267 - we currently suffer on MSVC from an [upstream bug]
which although diagnosed to a particular revision isn't currently fixed
upstream (and the bug itself doesn't seem too active). This commit is a
partial revert of the suspected cause of this regression (found via a
bisection). I'm sort of hoping that this eventually gets fixed upstream with a
similar fix (which we can replace in our branch), but for now I'm also hoping
it's a relatively harmless change to have.
After applying these patches (plus one [backport] which should be [backported
upstream][llvm-back]) I believe we should have all tests working on all
platforms in our current test suite. I'm like 99% sure that we'll need some more
backports as issues are reported for LLVM 6 when this propagates through
nightlies, but that's sort of just par for the course nowadays!
In any case though some extra scrutiny of the patches here would definitely be
welcome, along with scrutiny of the "missing patches" like a [change to pass
manager order](rust-lang/llvm@27174447533), [another change to pass manager
order](rust-lang/llvm@c782febb7b9), some [compile fixes for
sparc](rust-lang/llvm@1a83de63c42), and some [fixes for
solaris](rust-lang/llvm@c2bfe0abb).
[patches4]: https://github.com/rust-lang/llvm/compare/5401fdf23...rust-llvm-release-4-0-1
[backport]: https://github.com/rust-lang/llvm/commit/5c54c252db
[llvm-back]: https://bugs.llvm.org/show_bug.cgi?id=36114
[upstream bug]: https://bugs.llvm.org/show_bug.cgi?id=36096
---
The update to LLVM 6 is desirable for a number of reasons, notably:
* This'll allow us to keep up with the upstream wasm backend, picking up new
features as they start landing.
* Upstream LLVM has fixed a number of SIMD-related compilation errors,
especially around AVX-512 and such.
* There's a few assorted known bugs which are fixed in LLVM 5 and aren't fixed
in the LLVM 4 branch we're using.
* Overall it's not a great idea to stagnate with our codegen backend!
This update is mostly powered by #47730 which is allowing us to update LLVM
*independent* of the version of LLVM that Emscripten is locked to. This means
that when compiling code for Emscripten we'll still be using the old LLVM 4
backend, but when compiling code for any other target we'll be using the new
LLVM 6 target. Once Emscripten updates we may no longer need this distinction,
but we're not sure when that will happen!
Closes #43370
Closes #43418
Closes #47015
Closes #47683
Closes rust-lang-nursery/stdsimd#157
Closes rust-lang-nursery/rust-wasm#3
2018-01-22 16:23:30 -06:00
|
|
|
if target != build.build && !emscripten {
|
rustc: Split Emscripten to a separate codegen backend
This commit introduces a separately compiled backend for Emscripten, avoiding
compiling the `JSBackend` target in the main LLVM codegen backend. This builds
on the foundation provided by #47671 to create a new codegen backend dedicated
solely to Emscripten, removing the `JSBackend` of the main codegen backend in
the process.
A new field was added to each target for this commit which specifies the backend
to use for translation, the default being `llvm` which is the main backend that
we use. The Emscripten targets specify an `emscripten` backend instead of the
main `llvm` one.
There's a whole bunch of consequences of this change, but I'll try to enumerate
them here:
* A *second* LLVM submodule was added in this commit. The main LLVM submodule
will soon start to drift from the Emscripten submodule, but currently they're
both at the same revision.
* Logic was added to rustbuild to *not* build the Emscripten backend by default.
This is gated behind a `--enable-emscripten` flag to the configure script. By
default users should neither check out the emscripten submodule nor compile
it.
* The `init_repo.sh` script was updated to fetch the Emscripten submodule from
GitHub the same way we do the main LLVM submodule (a tarball fetch).
* The Emscripten backend, turned off by default, is still turned on for a number
of targets on CI. We'll only be shipping an Emscripten backend with Tier 1
platforms, though. All cross-compiled platforms will not be receiving an
Emscripten backend yet.
This commit means that when you download the `rustc` package in Rustup for Tier
1 platforms you'll be receiving two trans backends, one for Emscripten and one
that's the general LLVM backend. If you never compile for Emscripten you'll
never use the Emscripten backend, so we may update this one day to only download
the Emscripten backend when you add the Emscripten target. For now though it's
just an extra 10MB gzip'd.
Closes #46819
2018-01-24 10:22:34 -06:00
|
|
|
builder.ensure(Llvm {
|
|
|
|
target: build.build,
|
|
|
|
emscripten: false,
|
|
|
|
});
|
2017-07-04 20:41:43 -05:00
|
|
|
// FIXME: if the llvm root for the build triple is overridden then we
|
|
|
|
// should use llvm-tblgen from there, also should verify that it
|
|
|
|
// actually exists most of the time in normal installs of LLVM.
|
2017-07-13 19:48:44 -05:00
|
|
|
let host = build.llvm_out(build.build).join("bin/llvm-tblgen");
|
2017-07-04 20:41:43 -05:00
|
|
|
cfg.define("CMAKE_CROSSCOMPILING", "True")
|
|
|
|
.define("LLVM_TABLEGEN", &host);
|
2017-07-28 14:17:52 -05:00
|
|
|
|
|
|
|
if target.contains("netbsd") {
|
|
|
|
cfg.define("CMAKE_SYSTEM_NAME", "NetBSD");
|
|
|
|
} else if target.contains("freebsd") {
|
|
|
|
cfg.define("CMAKE_SYSTEM_NAME", "FreeBSD");
|
|
|
|
}
|
|
|
|
|
|
|
|
cfg.define("LLVM_NATIVE_BUILD", build.llvm_out(build.build).join("build"));
|
2017-07-04 20:41:43 -05:00
|
|
|
}
|
2017-02-25 11:53:46 -06:00
|
|
|
|
2018-02-10 14:09:25 -06:00
|
|
|
configure_cmake(build, target, &mut cfg, false);
|
2017-07-04 20:41:43 -05:00
|
|
|
|
|
|
|
// FIXME: we don't actually need to build all LLVM tools and all LLVM
|
|
|
|
// libraries here, e.g. we just want a few components and a few
|
|
|
|
// tools. Figure out how to filter them down and only build the right
|
|
|
|
// tools and libs on all platforms.
|
|
|
|
cfg.build();
|
|
|
|
|
|
|
|
t!(t!(File::create(&done_stamp)).write_all(rebuild_trigger_contents.as_bytes()));
|
rustc: Split Emscripten to a separate codegen backend
This commit introduces a separately compiled backend for Emscripten, avoiding
compiling the `JSBackend` target in the main LLVM codegen backend. This builds
on the foundation provided by #47671 to create a new codegen backend dedicated
solely to Emscripten, removing the `JSBackend` of the main codegen backend in
the process.
A new field was added to each target for this commit which specifies the backend
to use for translation, the default being `llvm` which is the main backend that
we use. The Emscripten targets specify an `emscripten` backend instead of the
main `llvm` one.
There's a whole bunch of consequences of this change, but I'll try to enumerate
them here:
* A *second* LLVM submodule was added in this commit. The main LLVM submodule
will soon start to drift from the Emscripten submodule, but currently they're
both at the same revision.
* Logic was added to rustbuild to *not* build the Emscripten backend by default.
This is gated behind a `--enable-emscripten` flag to the configure script. By
default users should neither check out the emscripten submodule nor compile
it.
* The `init_repo.sh` script was updated to fetch the Emscripten submodule from
GitHub the same way we do the main LLVM submodule (a tarball fetch).
* The Emscripten backend, turned off by default, is still turned on for a number
of targets on CI. We'll only be shipping an Emscripten backend with Tier 1
platforms, though. All cross-compiled platforms will not be receiving an
Emscripten backend yet.
This commit means that when you download the `rustc` package in Rustup for Tier
1 platforms you'll be receiving two trans backends, one for Emscripten and one
that's the general LLVM backend. If you never compile for Emscripten you'll
never use the Emscripten backend, so we may update this one day to only download
the Emscripten backend when you add the Emscripten target. For now though it's
just an extra 10MB gzip'd.
Closes #46819
2018-01-24 10:22:34 -06:00
|
|
|
|
|
|
|
build_llvm_config
|
2017-07-04 20:41:43 -05:00
|
|
|
}
|
2015-11-19 17:20:12 -06:00
|
|
|
}
|
|
|
|
|
|
|
|
fn check_llvm_version(build: &Build, llvm_config: &Path) {
|
|
|
|
if !build.config.llvm_version_check {
|
|
|
|
return
|
|
|
|
}
|
|
|
|
|
|
|
|
let mut cmd = Command::new(llvm_config);
|
|
|
|
let version = output(cmd.arg("--version"));
|
2017-10-16 14:57:37 -05:00
|
|
|
let mut parts = version.split('.').take(2)
|
|
|
|
.filter_map(|s| s.parse::<u32>().ok());
|
|
|
|
if let (Some(major), Some(minor)) = (parts.next(), parts.next()) {
|
|
|
|
if major > 3 || (major == 3 && minor >= 9) {
|
|
|
|
return
|
|
|
|
}
|
2015-11-19 17:20:12 -06:00
|
|
|
}
|
2017-10-16 14:57:37 -05:00
|
|
|
panic!("\n\nbad LLVM version: {}, need >=3.9\n\n", version)
|
2015-11-19 17:20:12 -06:00
|
|
|
}
|
|
|
|
|
rust: Import LLD for linking wasm objects
This commit imports the LLD project from LLVM to serve as the default linker for
the `wasm32-unknown-unknown` target. The `binaryen` submoule is consequently
removed along with "binaryen linker" support in rustc.
Moving to LLD brings with it a number of benefits for wasm code:
* LLD is itself an actual linker, so there's no need to compile all wasm code
with LTO any more. As a result builds should be *much* speedier as LTO is no
longer forcibly enabled for all builds of the wasm target.
* LLD is quickly becoming an "official solution" for linking wasm code together.
This, I believe at least, is intended to be the main supported linker for
native code and wasm moving forward. Picking up support early on should help
ensure that we can help LLD identify bugs and otherwise prove that it works
great for all our use cases!
* Improvements to the wasm toolchain are currently primarily focused around LLVM
and LLD (from what I can tell at least), so it's in general much better to be
on this bandwagon for bugfixes and new features.
* Historical "hacks" like `wasm-gc` will soon no longer be necessary, LLD
will [natively implement][gc] `--gc-sections` (better than `wasm-gc`!) which
means a postprocessor is no longer needed to show off Rust's "small wasm
binary size".
LLD is added in a pretty standard way to rustc right now. A new rustbuild target
was defined for building LLD, and this is executed when a compiler's sysroot is
being assembled. LLD is compiled against the LLVM that we've got in tree, which
means we're currently on the `release_60` branch, but this may get upgraded in
the near future!
LLD is placed into rustc's sysroot in a `bin` directory. This is similar to
where `gcc.exe` can be found on Windows. This directory is automatically added
to `PATH` whenever rustc executes the linker, allowing us to define a `WasmLd`
linker which implements the interface that `wasm-ld`, LLD's frontend, expects.
Like Emscripten the LLD target is currently only enabled for Tier 1 platforms,
notably OSX/Windows/Linux, and will need to be installed manually for compiling
to wasm on other platforms. LLD is by default turned off in rustbuild, and
requires a `config.toml` option to be enabled to turn it on.
Finally the unstable `#![wasm_import_memory]` attribute was also removed as LLD
has a native option for controlling this.
[gc]: https://reviews.llvm.org/D42511
2017-08-26 20:30:12 -05:00
|
|
|
fn configure_cmake(build: &Build,
|
|
|
|
target: Interned<String>,
|
2018-02-10 14:09:25 -06:00
|
|
|
cfg: &mut cmake::Config,
|
|
|
|
building_dist_binaries: bool) {
|
rust: Import LLD for linking wasm objects
This commit imports the LLD project from LLVM to serve as the default linker for
the `wasm32-unknown-unknown` target. The `binaryen` submoule is consequently
removed along with "binaryen linker" support in rustc.
Moving to LLD brings with it a number of benefits for wasm code:
* LLD is itself an actual linker, so there's no need to compile all wasm code
with LTO any more. As a result builds should be *much* speedier as LTO is no
longer forcibly enabled for all builds of the wasm target.
* LLD is quickly becoming an "official solution" for linking wasm code together.
This, I believe at least, is intended to be the main supported linker for
native code and wasm moving forward. Picking up support early on should help
ensure that we can help LLD identify bugs and otherwise prove that it works
great for all our use cases!
* Improvements to the wasm toolchain are currently primarily focused around LLVM
and LLD (from what I can tell at least), so it's in general much better to be
on this bandwagon for bugfixes and new features.
* Historical "hacks" like `wasm-gc` will soon no longer be necessary, LLD
will [natively implement][gc] `--gc-sections` (better than `wasm-gc`!) which
means a postprocessor is no longer needed to show off Rust's "small wasm
binary size".
LLD is added in a pretty standard way to rustc right now. A new rustbuild target
was defined for building LLD, and this is executed when a compiler's sysroot is
being assembled. LLD is compiled against the LLVM that we've got in tree, which
means we're currently on the `release_60` branch, but this may get upgraded in
the near future!
LLD is placed into rustc's sysroot in a `bin` directory. This is similar to
where `gcc.exe` can be found on Windows. This directory is automatically added
to `PATH` whenever rustc executes the linker, allowing us to define a `WasmLd`
linker which implements the interface that `wasm-ld`, LLD's frontend, expects.
Like Emscripten the LLD target is currently only enabled for Tier 1 platforms,
notably OSX/Windows/Linux, and will need to be installed manually for compiling
to wasm on other platforms. LLD is by default turned off in rustbuild, and
requires a `config.toml` option to be enabled to turn it on.
Finally the unstable `#![wasm_import_memory]` attribute was also removed as LLD
has a native option for controlling this.
[gc]: https://reviews.llvm.org/D42511
2017-08-26 20:30:12 -05:00
|
|
|
if build.config.ninja {
|
|
|
|
cfg.generator("Ninja");
|
|
|
|
}
|
|
|
|
cfg.target(&target)
|
|
|
|
.host(&build.config.build);
|
|
|
|
|
|
|
|
let sanitize_cc = |cc: &Path| {
|
|
|
|
if target.contains("msvc") {
|
|
|
|
OsString::from(cc.to_str().unwrap().replace("\\", "/"))
|
|
|
|
} else {
|
|
|
|
cc.as_os_str().to_owned()
|
|
|
|
}
|
|
|
|
};
|
|
|
|
|
|
|
|
// MSVC with CMake uses msbuild by default which doesn't respect these
|
|
|
|
// vars that we'd otherwise configure. In that case we just skip this
|
|
|
|
// entirely.
|
|
|
|
if target.contains("msvc") && !build.config.ninja {
|
|
|
|
return
|
|
|
|
}
|
|
|
|
|
|
|
|
let cc = build.cc(target);
|
|
|
|
let cxx = build.cxx(target).unwrap();
|
|
|
|
|
|
|
|
// Handle msvc + ninja + ccache specially (this is what the bots use)
|
|
|
|
if target.contains("msvc") &&
|
|
|
|
build.config.ninja &&
|
|
|
|
build.config.ccache.is_some() {
|
|
|
|
let mut cc = env::current_exe().expect("failed to get cwd");
|
|
|
|
cc.set_file_name("sccache-plus-cl.exe");
|
|
|
|
|
|
|
|
cfg.define("CMAKE_C_COMPILER", sanitize_cc(&cc))
|
|
|
|
.define("CMAKE_CXX_COMPILER", sanitize_cc(&cc));
|
|
|
|
cfg.env("SCCACHE_PATH",
|
|
|
|
build.config.ccache.as_ref().unwrap())
|
|
|
|
.env("SCCACHE_TARGET", target);
|
|
|
|
|
|
|
|
// If ccache is configured we inform the build a little differently hwo
|
|
|
|
// to invoke ccache while also invoking our compilers.
|
|
|
|
} else if let Some(ref ccache) = build.config.ccache {
|
|
|
|
cfg.define("CMAKE_C_COMPILER", ccache)
|
|
|
|
.define("CMAKE_C_COMPILER_ARG1", sanitize_cc(cc))
|
|
|
|
.define("CMAKE_CXX_COMPILER", ccache)
|
|
|
|
.define("CMAKE_CXX_COMPILER_ARG1", sanitize_cc(cxx));
|
|
|
|
} else {
|
|
|
|
cfg.define("CMAKE_C_COMPILER", sanitize_cc(cc))
|
|
|
|
.define("CMAKE_CXX_COMPILER", sanitize_cc(cxx));
|
|
|
|
}
|
|
|
|
|
|
|
|
cfg.build_arg("-j").build_arg(build.jobs().to_string());
|
|
|
|
cfg.define("CMAKE_C_FLAGS", build.cflags(target).join(" "));
|
|
|
|
let mut cxxflags = build.cflags(target).join(" ");
|
2018-02-10 14:09:25 -06:00
|
|
|
if building_dist_binaries {
|
|
|
|
if build.config.llvm_static_stdcpp && !target.contains("windows") {
|
|
|
|
cxxflags.push_str(" -static-libstdc++");
|
|
|
|
}
|
rust: Import LLD for linking wasm objects
This commit imports the LLD project from LLVM to serve as the default linker for
the `wasm32-unknown-unknown` target. The `binaryen` submoule is consequently
removed along with "binaryen linker" support in rustc.
Moving to LLD brings with it a number of benefits for wasm code:
* LLD is itself an actual linker, so there's no need to compile all wasm code
with LTO any more. As a result builds should be *much* speedier as LTO is no
longer forcibly enabled for all builds of the wasm target.
* LLD is quickly becoming an "official solution" for linking wasm code together.
This, I believe at least, is intended to be the main supported linker for
native code and wasm moving forward. Picking up support early on should help
ensure that we can help LLD identify bugs and otherwise prove that it works
great for all our use cases!
* Improvements to the wasm toolchain are currently primarily focused around LLVM
and LLD (from what I can tell at least), so it's in general much better to be
on this bandwagon for bugfixes and new features.
* Historical "hacks" like `wasm-gc` will soon no longer be necessary, LLD
will [natively implement][gc] `--gc-sections` (better than `wasm-gc`!) which
means a postprocessor is no longer needed to show off Rust's "small wasm
binary size".
LLD is added in a pretty standard way to rustc right now. A new rustbuild target
was defined for building LLD, and this is executed when a compiler's sysroot is
being assembled. LLD is compiled against the LLVM that we've got in tree, which
means we're currently on the `release_60` branch, but this may get upgraded in
the near future!
LLD is placed into rustc's sysroot in a `bin` directory. This is similar to
where `gcc.exe` can be found on Windows. This directory is automatically added
to `PATH` whenever rustc executes the linker, allowing us to define a `WasmLd`
linker which implements the interface that `wasm-ld`, LLD's frontend, expects.
Like Emscripten the LLD target is currently only enabled for Tier 1 platforms,
notably OSX/Windows/Linux, and will need to be installed manually for compiling
to wasm on other platforms. LLD is by default turned off in rustbuild, and
requires a `config.toml` option to be enabled to turn it on.
Finally the unstable `#![wasm_import_memory]` attribute was also removed as LLD
has a native option for controlling this.
[gc]: https://reviews.llvm.org/D42511
2017-08-26 20:30:12 -05:00
|
|
|
}
|
|
|
|
cfg.define("CMAKE_CXX_FLAGS", cxxflags);
|
|
|
|
if let Some(ar) = build.ar(target) {
|
|
|
|
if ar.is_absolute() {
|
|
|
|
// LLVM build breaks if `CMAKE_AR` is a relative path, for some reason it
|
|
|
|
// tries to resolve this path in the LLVM build directory.
|
|
|
|
cfg.define("CMAKE_AR", sanitize_cc(ar));
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
if env::var_os("SCCACHE_ERROR_LOG").is_some() {
|
|
|
|
cfg.env("RUST_LOG", "sccache=warn");
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
#[derive(Debug, Copy, Clone, Hash, PartialEq, Eq)]
|
|
|
|
pub struct Lld {
|
|
|
|
pub target: Interned<String>,
|
|
|
|
}
|
|
|
|
|
|
|
|
impl Step for Lld {
|
|
|
|
type Output = PathBuf;
|
|
|
|
const ONLY_HOSTS: bool = true;
|
|
|
|
|
|
|
|
fn should_run(run: ShouldRun) -> ShouldRun {
|
|
|
|
run.path("src/tools/lld")
|
|
|
|
}
|
|
|
|
|
|
|
|
fn make_run(run: RunConfig) {
|
|
|
|
run.builder.ensure(Lld { target: run.target });
|
|
|
|
}
|
|
|
|
|
|
|
|
/// Compile LLVM for `target`.
|
|
|
|
fn run(self, builder: &Builder) -> PathBuf {
|
|
|
|
let target = self.target;
|
|
|
|
let build = builder.build;
|
|
|
|
|
|
|
|
let llvm_config = builder.ensure(Llvm {
|
|
|
|
target: self.target,
|
|
|
|
emscripten: false,
|
|
|
|
});
|
|
|
|
|
|
|
|
let out_dir = build.lld_out(target);
|
|
|
|
let done_stamp = out_dir.join("lld-finished-building");
|
|
|
|
if done_stamp.exists() {
|
|
|
|
return out_dir
|
|
|
|
}
|
|
|
|
|
|
|
|
let _folder = build.fold_output(|| "lld");
|
|
|
|
println!("Building LLD for {}", target);
|
|
|
|
let _time = util::timeit();
|
|
|
|
t!(fs::create_dir_all(&out_dir));
|
|
|
|
|
|
|
|
let mut cfg = cmake::Config::new(build.src.join("src/tools/lld"));
|
2018-02-10 14:09:25 -06:00
|
|
|
configure_cmake(build, target, &mut cfg, true);
|
rust: Import LLD for linking wasm objects
This commit imports the LLD project from LLVM to serve as the default linker for
the `wasm32-unknown-unknown` target. The `binaryen` submoule is consequently
removed along with "binaryen linker" support in rustc.
Moving to LLD brings with it a number of benefits for wasm code:
* LLD is itself an actual linker, so there's no need to compile all wasm code
with LTO any more. As a result builds should be *much* speedier as LTO is no
longer forcibly enabled for all builds of the wasm target.
* LLD is quickly becoming an "official solution" for linking wasm code together.
This, I believe at least, is intended to be the main supported linker for
native code and wasm moving forward. Picking up support early on should help
ensure that we can help LLD identify bugs and otherwise prove that it works
great for all our use cases!
* Improvements to the wasm toolchain are currently primarily focused around LLVM
and LLD (from what I can tell at least), so it's in general much better to be
on this bandwagon for bugfixes and new features.
* Historical "hacks" like `wasm-gc` will soon no longer be necessary, LLD
will [natively implement][gc] `--gc-sections` (better than `wasm-gc`!) which
means a postprocessor is no longer needed to show off Rust's "small wasm
binary size".
LLD is added in a pretty standard way to rustc right now. A new rustbuild target
was defined for building LLD, and this is executed when a compiler's sysroot is
being assembled. LLD is compiled against the LLVM that we've got in tree, which
means we're currently on the `release_60` branch, but this may get upgraded in
the near future!
LLD is placed into rustc's sysroot in a `bin` directory. This is similar to
where `gcc.exe` can be found on Windows. This directory is automatically added
to `PATH` whenever rustc executes the linker, allowing us to define a `WasmLd`
linker which implements the interface that `wasm-ld`, LLD's frontend, expects.
Like Emscripten the LLD target is currently only enabled for Tier 1 platforms,
notably OSX/Windows/Linux, and will need to be installed manually for compiling
to wasm on other platforms. LLD is by default turned off in rustbuild, and
requires a `config.toml` option to be enabled to turn it on.
Finally the unstable `#![wasm_import_memory]` attribute was also removed as LLD
has a native option for controlling this.
[gc]: https://reviews.llvm.org/D42511
2017-08-26 20:30:12 -05:00
|
|
|
|
|
|
|
cfg.out_dir(&out_dir)
|
|
|
|
.profile("Release")
|
|
|
|
.define("LLVM_CONFIG_PATH", llvm_config)
|
|
|
|
.define("LLVM_INCLUDE_TESTS", "OFF");
|
|
|
|
|
|
|
|
cfg.build();
|
|
|
|
|
|
|
|
t!(File::create(&done_stamp));
|
|
|
|
out_dir
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2017-07-13 19:48:44 -05:00
|
|
|
#[derive(Debug, Copy, Clone, PartialEq, Eq, Hash)]
|
|
|
|
pub struct TestHelpers {
|
|
|
|
pub target: Interned<String>,
|
2017-07-04 20:41:43 -05:00
|
|
|
}
|
|
|
|
|
2017-07-13 19:48:44 -05:00
|
|
|
impl Step for TestHelpers {
|
2017-07-04 20:41:43 -05:00
|
|
|
type Output = ();
|
|
|
|
|
2017-07-18 19:03:38 -05:00
|
|
|
fn should_run(run: ShouldRun) -> ShouldRun {
|
2018-02-24 07:45:39 -06:00
|
|
|
run.path("src/test/auxiliary/rust_test_helpers.c")
|
2017-07-05 07:41:27 -05:00
|
|
|
}
|
|
|
|
|
2017-07-20 18:51:07 -05:00
|
|
|
fn make_run(run: RunConfig) {
|
|
|
|
run.builder.ensure(TestHelpers { target: run.target })
|
2017-07-05 07:41:27 -05:00
|
|
|
}
|
|
|
|
|
2017-07-04 20:41:43 -05:00
|
|
|
/// Compiles the `rust_test_helpers.c` library which we used in various
|
|
|
|
/// `run-pass` test suites for ABI testing.
|
|
|
|
fn run(self, builder: &Builder) {
|
|
|
|
let build = builder.build;
|
|
|
|
let target = self.target;
|
|
|
|
let dst = build.test_helpers_out(target);
|
2018-02-24 07:45:39 -06:00
|
|
|
let src = build.src.join("src/test/auxiliary/rust_test_helpers.c");
|
2017-07-04 20:41:43 -05:00
|
|
|
if up_to_date(&src, &dst.join("librust_test_helpers.a")) {
|
|
|
|
return
|
|
|
|
}
|
|
|
|
|
|
|
|
let _folder = build.fold_output(|| "build_test_helpers");
|
|
|
|
println!("Building test helpers");
|
|
|
|
t!(fs::create_dir_all(&dst));
|
2017-09-22 23:34:27 -05:00
|
|
|
let mut cfg = cc::Build::new();
|
2017-07-04 20:41:43 -05:00
|
|
|
|
|
|
|
// We may have found various cross-compilers a little differently due to our
|
|
|
|
// extra configuration, so inform gcc of these compilers. Note, though, that
|
|
|
|
// on MSVC we still need gcc's detection of env vars (ugh).
|
|
|
|
if !target.contains("msvc") {
|
|
|
|
if let Some(ar) = build.ar(target) {
|
|
|
|
cfg.archiver(ar);
|
|
|
|
}
|
|
|
|
cfg.compiler(build.cc(target));
|
2016-11-16 14:31:19 -06:00
|
|
|
}
|
|
|
|
|
2017-07-04 20:41:43 -05:00
|
|
|
cfg.cargo_metadata(false)
|
|
|
|
.out_dir(&dst)
|
2017-07-13 19:48:44 -05:00
|
|
|
.target(&target)
|
2017-07-04 20:41:43 -05:00
|
|
|
.host(&build.build)
|
|
|
|
.opt_level(0)
|
2017-09-05 10:48:47 -05:00
|
|
|
.warnings(false)
|
2017-07-04 20:41:43 -05:00
|
|
|
.debug(false)
|
2018-02-24 07:45:39 -06:00
|
|
|
.file(build.src.join("src/test/auxiliary/rust_test_helpers.c"))
|
2017-11-26 15:43:24 -06:00
|
|
|
.compile("rust_test_helpers");
|
2017-07-04 20:41:43 -05:00
|
|
|
}
|
2016-04-05 13:34:23 -05:00
|
|
|
}
|
2017-07-04 20:41:43 -05:00
|
|
|
|
2018-03-08 12:57:03 -06:00
|
|
|
const OPENSSL_VERS: &'static str = "1.0.2n";
|
2017-02-15 17:57:06 -06:00
|
|
|
const OPENSSL_SHA256: &'static str =
|
2018-03-08 12:57:03 -06:00
|
|
|
"370babb75f278c39e0c50e8c4e7493bc0f18db6867478341a832a982fd15a8fe";
|
2017-02-15 17:57:06 -06:00
|
|
|
|
2017-07-20 17:41:26 -05:00
|
|
|
#[derive(Debug, Copy, Clone, Hash, PartialEq, Eq)]
|
2017-07-13 19:48:44 -05:00
|
|
|
pub struct Openssl {
|
|
|
|
pub target: Interned<String>,
|
2017-07-04 20:41:43 -05:00
|
|
|
}
|
2017-02-15 17:57:06 -06:00
|
|
|
|
2017-07-13 19:48:44 -05:00
|
|
|
impl Step for Openssl {
|
2017-07-04 20:41:43 -05:00
|
|
|
type Output = ();
|
|
|
|
|
2017-07-18 19:03:38 -05:00
|
|
|
fn should_run(run: ShouldRun) -> ShouldRun {
|
|
|
|
run.never()
|
2017-07-05 07:41:27 -05:00
|
|
|
}
|
|
|
|
|
2017-07-04 20:41:43 -05:00
|
|
|
fn run(self, builder: &Builder) {
|
2017-07-05 11:46:41 -05:00
|
|
|
let build = builder.build;
|
2017-07-04 20:41:43 -05:00
|
|
|
let target = self.target;
|
|
|
|
let out = match build.openssl_dir(target) {
|
|
|
|
Some(dir) => dir,
|
|
|
|
None => return,
|
|
|
|
};
|
|
|
|
|
|
|
|
let stamp = out.join(".stamp");
|
|
|
|
let mut contents = String::new();
|
|
|
|
drop(File::open(&stamp).and_then(|mut f| f.read_to_string(&mut contents)));
|
|
|
|
if contents == OPENSSL_VERS {
|
|
|
|
return
|
2017-03-15 09:13:59 -05:00
|
|
|
}
|
2017-07-04 20:41:43 -05:00
|
|
|
t!(fs::create_dir_all(&out));
|
|
|
|
|
|
|
|
let name = format!("openssl-{}.tar.gz", OPENSSL_VERS);
|
|
|
|
let tarball = out.join(&name);
|
|
|
|
if !tarball.exists() {
|
|
|
|
let tmp = tarball.with_extension("tmp");
|
|
|
|
// originally from https://www.openssl.org/source/...
|
2017-09-15 18:04:13 -05:00
|
|
|
let url = format!("https://s3-us-west-1.amazonaws.com/rust-lang-ci2/rust-ci-mirror/{}",
|
2017-07-04 20:41:43 -05:00
|
|
|
name);
|
2017-10-11 12:20:55 -05:00
|
|
|
let mut last_error = None;
|
2017-07-04 20:41:43 -05:00
|
|
|
for _ in 0..3 {
|
|
|
|
let status = Command::new("curl")
|
|
|
|
.arg("-o").arg(&tmp)
|
2017-10-11 12:20:55 -05:00
|
|
|
.arg("-f") // make curl fail if the URL does not return HTTP 200
|
2017-07-04 20:41:43 -05:00
|
|
|
.arg(&url)
|
|
|
|
.status()
|
|
|
|
.expect("failed to spawn curl");
|
2017-10-11 12:20:55 -05:00
|
|
|
|
|
|
|
// Retry if download failed.
|
|
|
|
if !status.success() {
|
|
|
|
last_error = Some(status.to_string());
|
|
|
|
continue;
|
2017-07-04 20:41:43 -05:00
|
|
|
}
|
2017-10-11 12:20:55 -05:00
|
|
|
|
|
|
|
// Ensure the hash is correct.
|
|
|
|
let mut shasum = if target.contains("apple") || build.build.contains("netbsd") {
|
|
|
|
let mut cmd = Command::new("shasum");
|
|
|
|
cmd.arg("-a").arg("256");
|
|
|
|
cmd
|
|
|
|
} else {
|
|
|
|
Command::new("sha256sum")
|
|
|
|
};
|
|
|
|
let output = output(&mut shasum.arg(&tmp));
|
|
|
|
let found = output.split_whitespace().next().unwrap();
|
|
|
|
|
|
|
|
// If the hash is wrong, probably the download is incomplete or S3 served an error
|
|
|
|
// page. In any case, retry.
|
|
|
|
if found != OPENSSL_SHA256 {
|
|
|
|
last_error = Some(format!(
|
|
|
|
"downloaded openssl sha256 different\n\
|
|
|
|
expected: {}\n\
|
|
|
|
found: {}\n",
|
|
|
|
OPENSSL_SHA256,
|
|
|
|
found
|
|
|
|
));
|
|
|
|
continue;
|
|
|
|
}
|
|
|
|
|
|
|
|
// Everything is fine, so exit the retry loop.
|
|
|
|
last_error = None;
|
|
|
|
break;
|
2017-07-04 20:41:43 -05:00
|
|
|
}
|
2017-10-11 12:20:55 -05:00
|
|
|
if let Some(error) = last_error {
|
|
|
|
panic!("failed to download openssl source: {}", error);
|
2017-07-04 20:41:43 -05:00
|
|
|
}
|
|
|
|
t!(fs::rename(&tmp, &tarball));
|
2017-03-15 09:13:59 -05:00
|
|
|
}
|
2017-07-04 20:41:43 -05:00
|
|
|
let obj = out.join(format!("openssl-{}", OPENSSL_VERS));
|
|
|
|
let dst = build.openssl_install_dir(target).unwrap();
|
|
|
|
drop(fs::remove_dir_all(&obj));
|
|
|
|
drop(fs::remove_dir_all(&dst));
|
2017-08-31 09:22:39 -05:00
|
|
|
build.run(Command::new("tar").arg("zxf").arg(&tarball).current_dir(&out));
|
2017-07-04 20:41:43 -05:00
|
|
|
|
2017-08-28 11:22:11 -05:00
|
|
|
let mut configure = Command::new("perl");
|
|
|
|
configure.arg(obj.join("Configure"));
|
2017-07-04 20:41:43 -05:00
|
|
|
configure.arg(format!("--prefix={}", dst.display()));
|
|
|
|
configure.arg("no-dso");
|
|
|
|
configure.arg("no-ssl2");
|
|
|
|
configure.arg("no-ssl3");
|
|
|
|
|
2017-07-13 19:48:44 -05:00
|
|
|
let os = match &*target {
|
2017-07-04 20:41:43 -05:00
|
|
|
"aarch64-linux-android" => "linux-aarch64",
|
|
|
|
"aarch64-unknown-linux-gnu" => "linux-aarch64",
|
2017-09-05 11:55:25 -05:00
|
|
|
"aarch64-unknown-linux-musl" => "linux-aarch64",
|
2017-07-04 20:41:43 -05:00
|
|
|
"arm-linux-androideabi" => "android",
|
|
|
|
"arm-unknown-linux-gnueabi" => "linux-armv4",
|
|
|
|
"arm-unknown-linux-gnueabihf" => "linux-armv4",
|
|
|
|
"armv7-linux-androideabi" => "android-armv7",
|
|
|
|
"armv7-unknown-linux-gnueabihf" => "linux-armv4",
|
2018-01-04 10:55:04 -06:00
|
|
|
"i586-unknown-linux-gnu" => "linux-elf",
|
|
|
|
"i586-unknown-linux-musl" => "linux-elf",
|
2017-07-04 20:41:43 -05:00
|
|
|
"i686-apple-darwin" => "darwin-i386-cc",
|
|
|
|
"i686-linux-android" => "android-x86",
|
|
|
|
"i686-unknown-freebsd" => "BSD-x86-elf",
|
|
|
|
"i686-unknown-linux-gnu" => "linux-elf",
|
|
|
|
"i686-unknown-linux-musl" => "linux-elf",
|
2017-08-30 18:22:46 -05:00
|
|
|
"i686-unknown-netbsd" => "BSD-x86-elf",
|
2017-07-04 20:41:43 -05:00
|
|
|
"mips-unknown-linux-gnu" => "linux-mips32",
|
|
|
|
"mips64-unknown-linux-gnuabi64" => "linux64-mips64",
|
|
|
|
"mips64el-unknown-linux-gnuabi64" => "linux64-mips64",
|
|
|
|
"mipsel-unknown-linux-gnu" => "linux-mips32",
|
|
|
|
"powerpc-unknown-linux-gnu" => "linux-ppc",
|
2018-02-23 15:15:40 -06:00
|
|
|
"powerpc-unknown-linux-gnuspe" => "linux-ppc",
|
2018-02-16 14:29:24 -06:00
|
|
|
"powerpc-unknown-netbsd" => "BSD-generic32",
|
2017-07-04 20:41:43 -05:00
|
|
|
"powerpc64-unknown-linux-gnu" => "linux-ppc64",
|
|
|
|
"powerpc64le-unknown-linux-gnu" => "linux-ppc64le",
|
|
|
|
"s390x-unknown-linux-gnu" => "linux64-s390x",
|
2018-02-17 08:31:43 -06:00
|
|
|
"sparc-unknown-linux-gnu" => "linux-sparcv9",
|
2017-10-23 04:45:02 -05:00
|
|
|
"sparc64-unknown-linux-gnu" => "linux64-sparcv9",
|
2017-08-31 09:34:03 -05:00
|
|
|
"sparc64-unknown-netbsd" => "BSD-sparc64",
|
2017-07-04 20:41:43 -05:00
|
|
|
"x86_64-apple-darwin" => "darwin64-x86_64-cc",
|
|
|
|
"x86_64-linux-android" => "linux-x86_64",
|
|
|
|
"x86_64-unknown-freebsd" => "BSD-x86_64",
|
2017-10-29 12:42:04 -05:00
|
|
|
"x86_64-unknown-dragonfly" => "BSD-x86_64",
|
2017-07-04 20:41:43 -05:00
|
|
|
"x86_64-unknown-linux-gnu" => "linux-x86_64",
|
2018-02-23 18:08:02 -06:00
|
|
|
"x86_64-unknown-linux-gnux32" => "linux-x32",
|
2017-07-04 20:41:43 -05:00
|
|
|
"x86_64-unknown-linux-musl" => "linux-x86_64",
|
|
|
|
"x86_64-unknown-netbsd" => "BSD-x86_64",
|
|
|
|
_ => panic!("don't know how to configure OpenSSL for {}", target),
|
2017-02-15 17:57:06 -06:00
|
|
|
};
|
2017-07-04 20:41:43 -05:00
|
|
|
configure.arg(os);
|
|
|
|
configure.env("CC", build.cc(target));
|
|
|
|
for flag in build.cflags(target) {
|
|
|
|
configure.arg(flag);
|
2017-02-15 17:57:06 -06:00
|
|
|
}
|
2017-07-04 20:41:43 -05:00
|
|
|
// There is no specific os target for android aarch64 or x86_64,
|
|
|
|
// so we need to pass some extra cflags
|
|
|
|
if target == "aarch64-linux-android" || target == "x86_64-linux-android" {
|
|
|
|
configure.arg("-mandroid");
|
|
|
|
configure.arg("-fomit-frame-pointer");
|
|
|
|
}
|
2017-08-31 09:34:03 -05:00
|
|
|
if target == "sparc64-unknown-netbsd" {
|
|
|
|
// Need -m64 to get assembly generated correctly for sparc64.
|
|
|
|
configure.arg("-m64");
|
2017-08-31 09:36:10 -05:00
|
|
|
if build.build.contains("netbsd") {
|
|
|
|
// Disable sparc64 asm on NetBSD builders, it uses
|
|
|
|
// m4(1)'s -B flag, which NetBSD m4 does not support.
|
|
|
|
configure.arg("no-asm");
|
|
|
|
}
|
2017-08-31 09:34:03 -05:00
|
|
|
}
|
2017-07-04 20:41:43 -05:00
|
|
|
// Make PIE binaries
|
|
|
|
// Non-PIE linker support was removed in Lollipop
|
|
|
|
// https://source.android.com/security/enhancements/enhancements50
|
|
|
|
if target == "i686-linux-android" {
|
|
|
|
configure.arg("no-asm");
|
|
|
|
}
|
|
|
|
configure.current_dir(&obj);
|
|
|
|
println!("Configuring openssl for {}", target);
|
|
|
|
build.run_quiet(&mut configure);
|
|
|
|
println!("Building openssl for {}", target);
|
|
|
|
build.run_quiet(Command::new("make").arg("-j1").current_dir(&obj));
|
|
|
|
println!("Installing openssl for {}", target);
|
2018-03-09 20:49:28 -06:00
|
|
|
build.run_quiet(Command::new("make").arg("install").arg("-j1").current_dir(&obj));
|
2017-07-04 20:41:43 -05:00
|
|
|
|
|
|
|
let mut f = t!(File::create(&stamp));
|
|
|
|
t!(f.write_all(OPENSSL_VERS.as_bytes()));
|
2017-05-05 15:12:05 -05:00
|
|
|
}
|
2017-02-15 17:57:06 -06:00
|
|
|
}
|