about summary refs log tree commit diff
path: root/src/ci/docker/dist-x86_64-linux
AgeCommit message (Collapse)AuthorLines
2020-07-03ci: move all x86_64 runners to the host-x86_64 directoryPietro Albini-407/+0
We need to add runners designed for an aarch64 host system, and it'd be nice to return an error message if someone tries to run an image designed for an host architecture in another one. To start the work on this, this commit moves all the existing builders in the host-x86_64 directory, and changes the run.sh script to look up the image in the correct directory based on the host architecture.
2019-11-12ci: download curl and openssl from s3 for dist-x86_64-linuxPietro Albini-2/+9
CentOS 5 only supports SSLv3 without SNI, and to get newer protocols working we need to download and compile OpenSSL and cURL from our mirror. Because of that, we can't use the CDN, as CloudFront requires TLSv1 with SNI. This commit changes the dist-x86_64-linux image to bypass the CDN for OpenSSL and cURL.
2019-11-12ci: move mirrors to https://ci-mirrors.rust-lang.orgPietro Albini-2/+2
2019-11-07Update clang to build LLVM to 9.0.0Alex Crichton-2/+23
This also ensure that we're using the same clang version for all our major platforms instead of 8.0 on Linux and 7.0 on OSX/Windows.
2019-09-29Use https for curl when building for linuxTyler Mandry-2/+4
2019-08-12ci: move mirrors to their standalone bucketPietro Albini-1/+1
Currently mirrors are stored in the rust-lang-ci2 S3 bucket along with CI toolchains. This is problematic for multiple reasons: - CI IAM credentials are allowed to both edit and delete those files. A malicious user gaining access to those credentials would be able to change our mirrored dependencies, possibly backdooring the compiler. - Contents of the rust-lang-ci2 bucket are disposable except for the mirrors' content. When we implement backups for S3 buckets we'd have to replicate just that part of the bucket, complicating the backup logic and increasing the chance of mistakes. A standalone bucket will be way easier to backup. This commit switches our CI to use the new rust-lang-ci-mirrors bucket.
2019-05-29Update all s3 URLs used on CI with subdomainsAlex Crichton-1/+1
Ensure that they're all forwards-compatible with AWS updates happening next year by ensuring the bucket name shows up in the domain name. Closes #61168
2019-04-29build-gcc: Create missing cc symlinklzutao-0/+1
2019-02-12[CI] Update dist-x86_64-linux to GCC 5.5Josh Stone-22/+12
This also updates dist-i686-linux, since it borrows the same scripts. While we're at it, update llvm+clang+lld to llvm-project 8.0.0-rc2.
2018-12-25Remove licensesMark Rousskov-101/+0
2018-12-16rustc: Update Clang used to build LLVM on LInuxAlex Crichton-17/+14
This commit updates from LLVM 7.0.0 to git revisions of clang/llvm/lld to build LLVM on our dist builders for Linux. The goal of this is to fix #56849 by picking up a fix [1] in LLD. Closes #56849 [1]: https://github.com/llvm-mirror/lld/commit/3be4e82db78b46a8ca349b2b799dec620a6f159f
2018-11-14Update CI-clang to 7.0.0 for Linux dists.Michael Woerister-2/+2
2018-11-02Use `jemalloc-sys` on Linux and OSX compilersAlex Crichton-1/+2
This commit adds opt-in support to the compiler to link to `jemalloc` in the compiler. When activated the compiler will depend on `jemalloc-sys`, instruct jemalloc to unprefix its symbols, and then link to it. The feature is activated by default on Linux/OSX compilers for x86_64/i686 platforms, and it's not enabled anywhere else for now. We may be able to opt-in other platforms in the future! Also note that the opt-in only happens on CI, it's otherwise unconditionally turned off by default. Closes #36963
2018-10-20Update Cargo, build curl/OpenSSL statically via featuresAlex Crichton-0/+34
In addition to to updating Cargo's submodule and Cargo's dependencies, this also updates Cargo's build to build OpenSSL statically into Cargo as well as libcurl unconditionally. This removes OpenSSL build logic from the bootstrap code, and otherwise requests that even on OSX we build curl statically.
2018-09-28Add DIST_REQUIRE_ALL_TOOLS to CI scriptsChristian Poveda-0/+2
2018-08-20Compile LLVM with ThinLTO for x86_64 Linux dist builds.Michael Woerister-1/+4
2018-08-20Build LLD in addition to Clang in Linux CIMichael Woerister-0/+6
2018-05-09ci: Compile LLVM with Clang 6.0.0Alex Crichton-9/+81
Currently on CI we predominately compile LLVM with the default system compiler which means gcc on Linux, some version of Clang on OSX, MSVC on Windows, and gcc on MinGW. This commit switches Linux, OSX, and Windows to all use Clang 6.0.0 to build LLVM (aka the C/C++ compiler as part of the bootstrap). This looks to generate faster code according to #49879 which translates to a faster rustc (as LLVM internally is faster) The major changes here were to the containers that build Linux releases, basically adding a new step that uses the previous gcc 4.8 compiler to compile the next Clang 6.0.0 compiler. Otherwise the OSX and Windows scripts have been updated to download precompiled versions of Clang 6 and configure the build to use them. Note that `cc` was updated here to fix using `clang-cl` with `cc-rs` on MSVC, as well as an update to `sccache` on Windows which was needed to correctly work with `clang-cl`. Finally the MinGW compiler is entirely left out here intentionally as it's currently thought that Clang can't generate C++ code for MinGW and we need to use gcc, but this should be verified eventually.
2018-03-25Rollup merge of #49193 - davidtwco:issue-29893, r=alexcrichtonkennytm-1/+2
Host compiler documentation Fixes #29893. Rust Central Station PR: rust-lang/rust-central-station#40 r? @alexcrichton
2018-03-22Handle redirects correctly.kennytm-1/+1
2018-03-22Download the GCC artifacts from the HTTP server instead of FTP server.kennytm-0/+17
The former seems much more stable, in case the cache becomes invalidated.
2018-03-21Configure the dist-x86_64-linux builder to produce compiler documentationDavid Wood-1/+2
2018-03-03rust: Import LLD for linking wasm objectsAlex Crichton-3/+2
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
2018-03-02Remove --host and --target arguments to configureMark Simulacrum-1/+0
These arguments are passed to the relevant x.py invocation in all cases anyway. As such, there is no need to separately configure them. x.py will ignore the configuration when they are passed on the command line anyway.
2018-01-28rustc: Split Emscripten to a separate codegen backendAlex Crichton-1/+2
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
2017-11-13Use #!/usr/bin/env as shebang for Bash scriptsSébastien Santoro-8/+8
On some systems, the bash command could be available in another directory than /bin. As such, to offer an env shebang is more convenient. This make sense even for docker scripts, as you can use Docker on FreeBSD or SmartOS for example.
2017-09-16ci: Upload/download from a new S3 bucketAlex Crichton-1/+1
Moving buckets from us-east-1 to us-west-1 because us-west-1 is where rust-central-station itself runs and in general is where we have all our other buckets.
2017-08-26ci: Remove the need for `dumb-init`Alex Crichton-5/+0
Newer versions of Docker have a `--init` argument which spawns an init process in the container, which we should be able to use everywhere now.
2017-07-12Updated docker images to factor out common scriptsTy Coghlan-3/+2
2017-06-06Enable profiler selectively on some buildersMarco Castelluccio-1/+2
2017-05-25Update OpenSSL download locationAlex Crichton-2/+3
In rustbuild itself we download from our mirror but in the containers we don't do this yet. The OpenSSL download url changes from time to time (it breaks when they release a new version) so let's download from our mirror instead.
2017-05-17ci: allows shared scriptsMarco A L Barbosa-8/+8
2017-05-12Update sccache binaries to mozilla/sccache@d3627d766Alex Crichton-1/+1
This commit updates the sccache binaries to fix a cache load failure seen on #41926, fixed by mozilla/sccache#119
2017-04-29ci: Update sccache buildAlex Crichton-1/+1
Pulls in mozilla/sccache@ef0d77543 to fix #40240 again after the builds included in #41447 forgot to include the mio fixed included in #41076. Closes #40240
2017-04-27appveyor: Use Ninja/sccache on MSVCAlex Crichton-1/+1
Now that the final bug fixes have been merged into sccache we can start leveraging sccache on the MSVC builders on AppVeyor instead of relying on the ad-hoc caching strategy of trigger files and whatnot.
2017-04-27travis: Update sccache build usedAlex Crichton-1/+1
This build is no longer a forked version with temporary bugfixes, everything should be upstreamed!
2017-04-11use correct vault urlTim Neumann-1/+1
2017-04-04travis: Update sccache binariesAlex Crichton-1/+1
I've tracked down what I believe is the last spurious sccache failure on #40240 to behavior in mio (carllerche/mio#583), and this commit updates the binaries to a version which has that fix incorporated.
2017-04-04fix rollupTim Neumann-0/+6
2017-04-03travis: Split all dist builders in twoAlex Crichton-0/+353
Previously we would use one builder on Travis to produce two sets of host compilers for two different targets. Unfortunately though we've recently increased how much we're building for each target so this is starting to take unnecessarily long (#40804). This commit splits the dist builders in two by ensuring that we only dist one target on each builder, which should take a much shorter amount of time. This should also unblock other work such as landing the RLS (#40584).