| Age | Commit message (Collapse) | Author | Lines |
|---|
|
This enables better caching, since LLVM is only updated when needed, not
whenever x.py is run. Before, bootstrap.py had to use heuristics to
guess if LLVM would be needed, and updated the module more often than
necessary as a result.
This syncs the LLVM submodule only just before building the compiler, so
people working on the standard library never have to worry about it.
Example output:
```
Copying stage0 std from stage0 (x86_64-unknown-linux-gnu -> x86_64-unknown-linux-gnu / x86_64-unknown-linux-gnu)
Updating submodule src/llvm-project
Submodule 'src/llvm-project' (https://github.com/rust-lang/llvm-project.git) registered for path 'src/llvm-project'
Submodule path 'src/llvm-project': checked out 'f9a8d70b6e0365ac2172ca6b7f1de0341297458d'
```
- Don't try to update the LLVM submodule when using system LLVM
Previously, this would try to update LLVM unconditionally. Now the
submodule is only initialized if `llvm-config` is not set.
- Don't update LLVM submodule in dry runs
This prevents the following test failures:
```
running 17 tests
fatal: invalid gitfile format: /checkout/src/llvm-project/.git
test builder::tests::defaults::build_cross_compile ... FAILED
---- builder::tests::defaults::build_default stdout ----
thread 'main' panicked at 'command did not execute successfully: "git" "rev-parse" "HEAD"
expected success, got: exit code: 128', src/build_helper/lib.rs:139:9
```
- Try running git without --progress if it fails the first time
This avoids having to do version detection to see if --progress is
supported or not.
- Don't try to update submodules when the source repository isn't managed by git
- Update LLVM submodules that have already been checked out
- Only check for whether the submodule should be updated in lib.rs; update
it unconditionally in native.rs
|
|
|
|
- Add an assertion that `link-shared = true` when `thin-lto = true`.
Previously, link-shared would be silently overwritten.
- Get rid of `Option<bool>` in bootstrap/config.rs. Set defaults
immediately instead of delaying until later in bootstrap. This makes
it easier to find what the default value is.
- Remove redundant `config.x = false` when the default was already false
- Set defaults for `bindir` in `default_opts()` instead of `parse()`
- Update `download-ci-llvm = if-supported` option to match bootstrap.py
- Remove redundant check for link_shared. Previously, it was checked twice.
- Update various options in config.toml.example to their defaults.
Previously, some options showed an example value instead of the
default value.
- Fix incorrect defaults in config.toml.example
+ `use-libcxx` defaults to false
+ Add missing `check-stage = 0`
+ Update several defaults to be conditional (e.g. `if incremental { 10 } else { 100 }`)
- Remove redundant defaults in prose
- Use the same comment for the default and target-dependent `musl-root`
- Fix typos
- Link to `cc_detect` for `cc` and `cxx`, since the logic is ... complicated.
- Update more defaults to better reflect how they actually get set
- Remove ignored `gpg-password-file` option
This stopped being used in
https://github.com/rust-lang/rust/commit/7704d35accfe1b587ce41ea09ca3bf6a47aca117,
but was never removed from config.toml.
- Remove unused flags from `config.toml`
+ Disallow `infodir` and `localstatedir` in `config.toml`
+ Allow the flags in `./configure`, but give a warning that they will be
ignored.
+ Fix incorrect comment that `datadir` will be ignored.
Example output:
```
$ ./configure --set install.infodir=xxx
configure: processing command line
configure:
configure: install.infodir := xxx
configure: build.configure-args := ['--set', 'install.infodir=xxx']
warning: infodir will be ignored
configure:
configure: writing `config.toml` in current directory
configure:
configure: run `python /home/joshua/rustc3/x.py --help`
configure:
```
- Update CHANGELOG
- Add "as an example" where appropriate
- Link to an issue instead of to ephemeral chats
|
|
|
|
When cross-compiling to solaris/illumos targets, set
CMAKE_SYSTEM_NAME to SunOS.
|
|
|
|
This reverts commit cb6787ae82d388045cdf6b5dc73787d828d91feb, reversing
changes made to 0248c6f178ab3a4d2ec702b7d418ff8375ab0515.
|
|
This avoids a conflict if llvm.thin-lto=true is combined with an
explicit llvm.use-linker=lld.
|
|
LLVM 12 no longer builds with Python 2, so install Python 3 in
preparatin.
However, Clang 10 does not build with Python 3, so we need update
to Clang 11 as well, which supports both.
Unfortunately, doing so results in errors while linking the
libLLVM.so into other binaries:
> __morestack: invalid needed version 2
This is fixed by using LLD instead. Possibly this is due to a binutils
linker bug, but updating to the latest binutils version does not fix
it.
|
|
- Don't ignore packaging `llvm/lib/` for `rust-dev` when LLVM is linked
statically
- Add `link-type.txt` so bootstrap knows whether llvm was linked
statically or dynamically
- Don't assume CI LLVM is linked dynamically in `bootstrap::config`
- Fall back to dynamic linking if `link-type.txt` doesn't exist
- Fix existing bug that split the output of `llvm-config` on lines, not spaces
- Enable building LLVM tests
This works around the following llvm bug:
```
llvm-config: error: component libraries and shared library
llvm-config: error: missing: /home/joshua/rustc2/build/x86_64-unknown-linux-gnu/llvm/build/lib/libgtest.a
llvm-config: error: missing: /home/joshua/rustc2/build/x86_64-unknown-linux-gnu/llvm/build/lib/libgtest_main.a
llvm-config: error: missing: /home/joshua/rustc2/build/x86_64-unknown-linux-gnu/llvm/build/lib/libLLVMTestingSupport.a
thread 'main' panicked at 'command did not execute successfully: "/home/joshua/rustc2/build/x86_64-unknown-linux-gnu/llvm/build/bin/llvm-config" "--libfiles"
```
I'm not sure why llvm-config thinks these are required, but to avoid
the error, this builds them anyway.
- Temporarily set windows as the try builder. This should be reverted
before merging.
- Bump version of `download-ci-llvm-stamp`
`src/llvm-project` hasn't changed, but the generated tarball has.
- Only special case MacOS when dynamic linking. Static linking works fine.
- Store `link-type.txt` to the top-level of the tarball
This allows writing the link type unconditionally. Previously, bootstrap
had to keep track of whether the file IO *would* succeed (it would fail
if `lib/` didn't exist), which was prone to bugs.
- Make `link-type.txt` required
Anyone downloading this from CI should be using a version of bootstrap
that matches the version of the uploaded artifacts. So a missing
link-type indicates a bug in x.py.
|
|
|
|
|
|
|
|
This resolves issues where the cross-build of LLVM fails because it tries to
link to the host's system libraries instead of the target's system libraries.
|
|
LVI hardening tests
Mitigating the speculative execution LVI attack against SGX enclaves requires compiler changes (i.e., adding lfences). This pull requests adds various tests to check if this happens correctly.
|
|
|
|
Don't dynamically link LLVM tools unless rustc is too
This PR initially tried to support link-shared on all of our target platforms (other than Windows), but ran into a number of difficulties:
* LLVM doesn't really support a shared link on macOS (llvm-config runs into problems with the version suffix)
* LLVM doesn't seem to support a shared link when cross-compiling (the libLLVM.so ends up empty and symbols are not found)
So, this PR has now been revised such that we don't attempt to dynamically link LLVM tools (even if that would, otherwise, be supported) on targets where LLVM is statically linked to rustc. Currently that's basically everything except for x86_64-unknown-linux-gnu (where we dynamically link to avoid rerunning ThinLTO in each stage).
Follow-up to #76708.
Fixes #76698.
|
|
Previously we would have some platforms where LLVM was linked to rustc
statically, but to the LLVM tools dynamically. That meant we were distributing
two copies of LLVM: one as a separate dylib and one statically linked in to
librustc_driver.
|
|
The Rust version number is currently embedded in bootstrap's source
code, which makes it hard to update it automatically or access it
outside of ./x.py (as you'd have to parse the source code).
This commit moves the version number to a standalone plaintext file,
which makes accessing or updating it trivial.
|
|
Windows doesn't quite support dynamic linking to LLVM yet, but on other
platforms we do. In #76708, it was discovered that we dynamically link to LLVM
from the LLVM tools (e.g., rust-lld), so we need the shared LLVM library to link
against. That means that if we do not have a shared link to LLVM, and want LLVM
tools to work, we'd be shipping two copies of LLVM on all of these platforms:
one in librustc_driver and one in libLLVM.
Also introduce an error into rustbuild if we do end up configured for shared
linking on Windows.
|
|
are no longer supported by llvm
CMake Warning:
Manually-specified variables were not used by the project:
PYTHON_EXECUTABLE
WITH_POLLY
|
|
It isn't practical to determine whether we'll build LLVM very early in the
pipeline, so move the ninja checking to a dynamic check.
|
|
|
|
clippy::print_literal
clippy::clone_on_copy
clippy::single_char_pattern
clippy::into_iter_on_ref
clippy::match_like_matches_macro
|
|
cmake-rs@8141f0e changed the logic for handling asm compiler flags.
This change was pulled in with the cmake 0.1.42 -> 0.1.44 update.
This introduced two new flags to the LLVM build, breaking it:
"-DCMAKE_ASM_FLAGS= -ffunction-sections -fdata-sections -fPIC -m64"
"-DCMAKE_ASM_COMPILER=/usr/bin/cc"
This patch should resolve the breakage by handling it in bootstrap.
|
|
Add sanitizer support on FreeBSD
Restarting #47337. Everything is better now, no more weird llvm problems, well not everything:
Unfortunately, the sanitizers don't have proper support for versioned symbols (https://github.com/google/sanitizers/issues/628), so `libc`'s usage of `stat@FBSD_1.0` and so on explodes, e.g. in calling `std::fs::metadata`.
Building std (now easy thanks to cargo `-Zbuild-std`) and libc with `freebsd12/13` config via the `LIBC_CI=1` env variable is a good workaround…
```
LIBC_CI=1 RUSTFLAGS="-Z sanitizer=address" cargo +san-test -Zbuild-std run --target x86_64-unknown-freebsd --verbose
```
…*except* std won't build because there's no `st_lspare` in the ino64 version of the struct, so an std patch is required:
```diff
--- i/src/libstd/os/freebsd/fs.rs
+++ w/src/libstd/os/freebsd/fs.rs
@@ -66,8 +66,6 @@ pub trait MetadataExt {
fn st_flags(&self) -> u32;
#[stable(feature = "metadata_ext2", since = "1.8.0")]
fn st_gen(&self) -> u32;
- #[stable(feature = "metadata_ext2", since = "1.8.0")]
- fn st_lspare(&self) -> u32;
}
#[stable(feature = "metadata_ext", since = "1.1.0")]
@@ -136,7 +134,4 @@ impl MetadataExt for Metadata {
fn st_flags(&self) -> u32 {
self.as_inner().as_inner().st_flags as u32
}
- fn st_lspare(&self) -> u32 {
- self.as_inner().as_inner().st_lspare as u32
- }
}
```
I guess std could like.. detect that `libc` isn't built for the old ABI, and replace the implementation of `st_lspare` with a panic?
|
|
Set CMAKE_SYSTEM_NAME when cross-compiling
Configure CMAKE_SYSTEM_NAME when cross-compiling in `configure_cmake`,
to tell CMake about target system. Previously this was done only for
LLVM step and now applies more generally to steps using cmake.
Helps with #74576.
|
|
|
|
Configure CMAKE_SYSTEM_NAME when cross-compiling in `configure_cmake`,
to tell CMake about target system. Previously this was done only for
LLVM step and now applies more generally to steps using cmake.
|
|
|
|
`rustc` allows passing in predefined target triples as well as JSON
target specification files. This change allows bootstrap to have the
first inkling about those differences. This allows building a
cross-compiler for an out-of-tree architecture (even though that
compiler won't work for other reasons).
Even if no one ever uses this functionality, I think the newtype
around the `Interned<String>` improves the readability of the code.
|
|
RISC-V GNU/Linux as host platform
This PR add a new builder named `dist-riscv64-linux` that builds the compiler toolchain for RISC-V 64-bit GNU/Linux.
r? @alexcrichton
|
|
When running a command like `DESTDIR=foo x.py install` in a completely
clean build directory, this will cause LLVM to be installed into
`DESTDIR`, which then causes the build to fail later when it attempts
to *use* those LLVM files.
|
|
|
|
When cross-compiling, the LLVM build system recurses to build tools
that need to run on the host system. However, since we pass cmake defines
to set the compiler and target, LLVM still compiles these tools for the
target system, rather than the host. The tools then fail to execute
during the LLVM build.
This change sets defines for the tools that need to run on the
host (llvm-nm, llvm-tablegen, and llvm-config), so that the LLVM build
does not attempt to build them, and instead relies on the tools already built.
If compiling with clang-cl, this change also adds the `--target` option
to specify the target triple. MSVC compilers do not require this, since there
is a separate compiler binary for cross-compilation.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Enable LLVM zlib
Compilers may generate ELF objects with compressed sections (although rustc currently doesn't do this). Currently, when linking these with `rust-lld`, you'll get this error:
`rust-lld: error: ...: contains a compressed section, but zlib is not available`
This enables zlib when building LLVM.
|
|
|
|
|
|
|
|
|
|
|
|
it's not been built since a long time ago
|
|
The extracted function can be used by the rest of bootstrap to detect if we've
already built an up-to-date LLVM (and so it's safe for us to either request it
or pretend it exists).
|
|
Looks like the native build system isn't great a coping with this, so
try to work around that with a few workarounds.
|
