| Age | Commit message (Collapse) | Author | Lines |
|---|
|
In Linux distributions, it is often necessary to rebuild packages for
cases like applying new patches or linking against new system libraries.
In this scenario, the rustc in the distro build environment may already
match the current release that we're trying to rebuild. Thus we don't
want to use the prior release's bootstrap key, nor `--cfg stage0` for
the prior unstable features.
The new `configure --enable-local-rebuild` option specifies that we are
rebuilding from the current release. The current bootstrap key is used
for the local rustc, and current stage1 features are also assumed.
|
|
|
|
Because GitHub publishes broken tarballs on our behalf that we can't
disable, this adds a check that src/liblibc exists, and then
complains if not.
|
|
Sanity check Python on OSX for LLDB tests
Two primary changes:
* Don't get past the configure stage if `python` isn't coming from `/usr/bin`
* Call `debugger.Terminate()` to prevent segfaults on newer versions of LLDB.
Closes #32994
|
|
|
|
|
|
Force usage of /usr/bin/python whenever we run LLDB tests on OSX because it
looks like no other Python will work.
|
|
mk: Hardcode the bootstrap key for each release
Starting with the 1.10.0 release we would like to bootstrap all compilers from
the previous stable release. For example the 1.10.0 compiler should bootstrap
from the literal 1.9.0 release artifacts. To do this, however, we need a way to
enable unstable features temporarily in a stable compiler (as the released
compiler is stable), but it turns out we already have a way to do that!
At compile time the configure script selects a `CFG_BOOTSTRAP_KEY` variable
value and then exports it into the makefiles. If the `RUSTC_BOOTSTRAP_KEY`
environment variable is set to this value, then the compiler is allowed to
"cheat" and use unstable features.
This method of choosing the bootstrap key, however, is problematic for the
intention of bootstrapping from the previous release. Each time a 1.9.0 compiler
is created, a new bootstrap key will be selected. That means that the 1.10.0
compiler will only compile from *our* literal release artifacts. Instead
distributions would like to bootstrap from their own compilers, so instead we
simply hardcode the bootstrap key for each release.
This patch uses the same `CFG_FILENAME_EXTRA` value (a hash of the release
string) as the bootstrap key. Consequently all 1.9.0 compilers, no matter where
they are compiled, will have the same bootstrap key. Additionally we won't need
to keep updating this as it'll be based on the release number anyway.
Once the 1.9.0 beta has been created, we can update the 1.10.0 nightly sources
(the `master` branch at that time) to bootstrap from that release using this
hard-coded bootstrap key. We will likely just hardcode into the makefiles what
the previous bootstrap key was and we'll change that whenever the stage0
compiler is updated.
|
|
Starting with the 1.10.0 release we would like to bootstrap all compilers from
the previous stable release. For example the 1.10.0 compiler should bootstrap
from the literal 1.9.0 release artifacts. To do this, however, we need a way to
enable unstable features temporarily in a stable compiler (as the released
compiler is stable), but it turns out we already have a way to do that!
At compile time the configure script selects a `CFG_BOOTSTRAP_KEY` variable
value and then exports it into the makefiles. If the `RUSTC_BOOTSTRAP_KEY`
environment variable is set to this value, then the compiler is allowed to
"cheat" and use unstable features.
This method of choosing the bootstrap key, however, is problematic for the
intention of bootstrapping from the previous release. Each time a 1.9.0 compiler
is created, a new bootstrap key will be selected. That means that the 1.10.0
compiler will only compile from *our* literal release artifacts. Instead
distributions would like to bootstrap from their own compilers, so instead we
simply hardcode the bootstrap key for each release.
This patch uses the same `CFG_FILENAME_EXTRA` value (a hash of the release
string) as the bootstrap key. Consequently all 1.9.0 compilers, no matter where
they are compiled, will have the same bootstrap key. Additionally we won't need
to keep updating this as it'll be based on the release number anyway.
Once the 1.9.0 beta has been created, we can update the 1.10.0 nightly sources
(the `master` branch at that time) to bootstrap from that release using this
hard-coded bootstrap key. We will likely just hardcode into the makefiles what
the previous bootstrap key was and we'll change that whenever the stage0
compiler is updated.
|
|
Our `codegen` test suite requires the LLVM `FileCheck` utility but unfortunately
this isn't always available in all custom LLVM roots (e.g. those specified via
`--llvm-root`). This commit adds a `./configure` option called
`--disable-codegen-tests` which will manually disable running these tests. In
the case that this option is passed we can forgo the need for the `FileCheck`
executable. Note that we still require `FileCheck` by default as we will attempt
to run these tests.
Closes #28667
|
|
Detect the triple in the configure script for probing MSVC shenanigans and also
be sure to use `llvm-config` from the build host and not the target when
configuring compiler-rt.
|
|
Rust 1.7.0 and newer appears to require LLVM 3.6.0 or newer when
building against a version that's out of the tree with the --llvm-root
flag.
Signed-off-by: Doug Goldstein <cardoe@cardoe.com>
|
|
|
|
|
|
The `--disable-jemalloc` configure option has a failure mode where it will
create a distribution that is not compatible with other compilers. For example
the nightly for Linux will assume that it will link to jemalloc by default as
an allocator for executable crates. If, however, a standard library is used
which was built via `./configure --disable-jemalloc` then this will fail
because the jemalloc crate wasn't built.
While this seems somewhat reasonable as a niche situation, the same mechanism is
used for disabling jemalloc for platforms that just don't support it. For
example if the rumprun target is compiled then the sibiling Linux target *also*
doesn't have jemalloc. This is currently a problem for our cross-build nightlies
which build many targets. If rumprun is also built, it will disable jemalloc for
all targets, which isn't desired.
This commit moves the platform-specific disabling of jemalloc as hardcoded logic
into the makefiles that is scoped per-platform. This way when configuring
multiple targets **without the `--disable-jemalloc` option specified** all
targets will get jemalloc as they should.
|
|
This removes creating some extraneous directories and also fixes some submodule management with out of tree builds.
Closes #31619
|
|
In other words, enforce what was documented in #30626 (and also stop blaming it on LLVM, we have at least one Python script of our own).
Also, there is no Python later than 2.7 and there never will be.
|
|
As part of the ./configure step don't create any directories if rustbuild is
enable as rustbuild will take care of everything.
|
|
This commit adds a `--enable-rustbuild` option to the configure script which
will copy a different `Makefile.in` into place to intercept all `make`
invocations.
Currently this makefile only has one target, but it's expected to be filled out
quite a bit over time!
|
|
This likely isn't always valid, and subverts auto-detection.
|
|
Backtraces, and the compilation of libbacktrace for asmjs, are disabled.
This port doesn't use jemalloc so, like pnacl, it disables jemalloc *for all targets*
in the configure file.
It disables stack protection.
|
|
|
|
|
|
This target covers MIPS devices that run the trunk version of OpenWRT.
The x86_64-unknown-linux-musl target always links statically to C libraries. For
the mips(el)-unknown-linux-musl target, we opt for dynamic linking (like most of
other targets do) to keep binary size down.
As for the C compiler flags used in the build system, we use the same flags used
for the mips(el)-unknown-linux-gnu target.
r? @alexcrichton
|
|
Buildbot was updated long ago to use the correct triples.
The putvar here is emitting garbage into `configure --help` so
I want it gone.
|
|
This target covers MIPS devices that run the trunk version of OpenWRT.
The x86_64-unknown-linux-musl target always links statically to C libraries. For
the mips(el)-unknown-linux-musl target, we opt for dynamic linking (like most of
other targets do) to keep binary size down.
As for the C compiler flags used in the build system, we use the same flags used
for the mips(el)-unknown-linux-gnu target.
|
|
The purpose of the translation item collector is to find all monomorphic instances of functions, methods and statics that need to be translated into LLVM IR in order to compile the current crate.
So far these instances have been discovered lazily during the trans path. For incremental compilation we want to know the set of these instances in advance, and that is what the trans::collect module provides.
In the future, incremental and regular translation will be driven by the collector implemented here.
|
|
|
|
|
|
We've been seeing a lot of timeouts in tests on the bots and investigation ended
pointing to jemalloc/jemalloc#315 as the culprit. Unfortunately it looks like
that doesn't seem to have a fix on the way soon, so let's temporarily downgrade
back to the previous version of jemalloc we were using (where #30434 was the
most recent upgrade)
|
|
We've been seeing a lot of timeouts in tests on the bots and investigation ended
pointing to jemalloc/jemalloc#315 as the culprit. Unfortunately it looks like
that doesn't seem to have a fix on the way soon, so let's temporarily downgrade
back to the previous version of jemalloc we were using (where #30434 was the
most recent upgrade)
|
|
|
|
I'm using clang 7.2 which works just fine to compile Rust with, but was disallowed.
|
|
This adds support for big endian and little endian PowerPC64.
make check runs clean apart from one big endian backtrace issue.
|
|
This mixes in additional information into the hash that is
passed to -C extra-filename. It can be used to further distinguish
the standard libraries if they must be installed next to each
other.
Closes #29559
|
|
On some weird setup where $SHELL is a relative path (can happen under GNU
Screen,) `file -L "$BIN_TO_PROBE"` fails and $CFG_CPUTYPE is wrongly set to
i686. We should not only check its string value but also permission on
filesystem.
|
|
This commit changes our distribution and in-tree sources to pass the `-C rpath`
flag by default during compiles. This means that from-source builds, including
our release channels, will have this option enabled as well. Motivated
by #29941, this change means that the compiler should be usable as-is on all
platforms just after extraction or installation. This experience is already true
on Windows but on Unixes you still need to set up LD_LIBRARY_PATH or the
equivalent, which can often be unfortunate.
This option was originally turned off by default for Linux distributions who
tend to take care of these sorts of details themselves, so it is expected that
all those builds of Rust will want to pass `--disable-rpath` to the configure
script to preserve that behavior.
Closes #29941
|
|
On some weird setup where $SHELL is a relative path (can happen under GNU
Screen,) `file -L "$BIN_TO_PROBE"` fails and $CFG_CPUTYPE is wrongly set to
i686. We should not only check its string value but also permission on
filesystem.
|
|
target
machine if available.
|
|
This handles cases when the LLVM used isn't configured will the 'usual'
targets. Also, cases where LLVM is shared are also handled (ie with
`LD_LIBRARY_PATH` etc).
|
|
This commit changes our distribution and in-tree sources to pass the `-C rpath`
flag by default during compiles. This means that from-source builds, including
our release channels, will have this option enabled as well. Motivated
by #29941, this change means that the compiler should be usable as-is on all
platforms just after extraction or installation. This experience is already true
on Windows but on Unixes you still need to set up LD_LIBRARY_PATH or the
equivalent, which can often be unfortunate.
This option was originally turned off by default for Linux distributions who
tend to take care of these sorts of details themselves, so it is expected that
all those builds of Rust will want to pass `--disable-rpath` to the configure
script to preserve that behavior.
Closes #29941
|
|
The Rust build scripts do work if the source directory contains spaces. I tried to make it work with spaces. I managed to get the Rust's and LLVM's configure scripts to work with spaces in the path, but I could not figure out how to get the Rust makefiles working.
So for now, this PR updates Rust's `configure` to abort if the source path contains spaces. I also added a note about spaces in the source path to the README.
I think this should close #18477 for now.
|
|
Debian wants to build all binaries with particular hardening flags.
The Rust makefiles are inconsistent in which architectures they
correctly include CFLAGS/etc from the enivoronment (see mk/cfg/*).
This patch adds LDFLAGS, and then unconditionally prepends
CFLAGS/LDFLAGS/etc to the build commands.
|
|
|
|
r? @alexcrichton
|
|
|
|
with all other platforms.
|
|
This reverts commit b09e8f51a26f9421d27fea4e1324b6ee24a26722.
|
|
|
|
Part of #28710
Landing pads during stage0 are now enabled by defaullt. Since this has its downsides and upsides either way, I made it possible to change the option through configure.
|
