Removes all target-specific knowledge from rustc. Some targets have changed
during this, but none of these should be very visible outside of
cross-compilation. The changes make our targets more consistent.
iX86-unknown-linux-gnu is now only available as i686-unknown-linux-gnu. We
used to accept any value of X greater than 1. i686 was released in 1995, and
should encompass the bare minimum of what Rust supports on x86 CPUs.
The only two windows targets are now i686-pc-windows-gnu and
x86_64-pc-windows-gnu.
The iOS target has been renamed from arm-apple-ios to arm-apple-darwin.
A complete list of the targets we accept now:
arm-apple-darwin
arm-linux-androideabi
arm-unknown-linux-gnueabi
arm-unknown-linux-gnueabihf
i686-apple-darwin
i686-pc-windows-gnu
i686-unknown-freebsd
i686-unknown-linux-gnu
mips-unknown-linux-gnu
mipsel-unknown-linux-gnu
x86_64-apple-darwin
x86_64-unknown-freebsd
x86_64-unknown-linux-gnu
x86_64-pc-windows-gnu
Closes#16093
[breaking-change]
Used aforementioned variants to extract options that have explicit
`putvar` calls associated with them in the subsequent code. When the
explicit `putvar` call was conditional on some potentially complex
condition, moved the `putvar` call out to the main control flow of the
script so that it always runs if necessary.
----
As a driveby fix, captured the error exit when doing the test run of
`rustc --version` from `CFG_LOCAL_RUST_ROOT`, and signal explicit
configure failure when it did not run successfully. (If we cannot run
`rustc`, we really shouldn't try to keep going.)
----
Finally, in response to review feedback, went through and identified
cases where we had been calling `putvar` manually (and thus my naive
translation used `opt_nosave`/`valopt_nosave`), and then verified
whether a manual `putvar` was necessary (i.e., was each variable in
question manually computed somewhere in the `configure` script).
In cases that did not meet this criteria, I revised the code to use
the `opt`/`valopt` directly and removed the corresponding `putvar`,
cleaning things up a teeny bit.
----
Fix#17887.
This commit removes the libuv and gyp submodules, as well as all build
infrastructure related to them.
For more context, see the [runtime removal
RFC](https://github.com/rust-lang/rfcs/pull/230)
[breaking-change]
Adds a new configure flag, --release-channel, which determines how the version
number should be augmented with a release label, as well as how the distribution
artifacts will be named. This is entirely for use by the build automation.
--release-channel can be either 'source', 'nightly', 'beta', or 'stable'.
Here's a summary of the affect of these values on version number and
artifact naming, respectively:
* source - '0.12.0-pre', 'rust-0.12.0-pre-...'
* nightly - '0.12.0-nightly', 'rust-nightly-...'
* beta - '0.12.0-beta', 'rust-beta-...'
* stable - '0.12.0', 'rust-0.12.0-...'
Per http://discuss.rust-lang.org/t/rfc-impending-changes-to-the-release-process/508/1
Not included are two required patches:
* LLVM: segmented stack support for DragonFly [1]
* jemalloc: simple configure patches
[1]: http://reviews.llvm.org/D4705
This commit disables rustc's emission of rpath attributes into dynamic libraries
and executables by default. The functionality is still preserved, but it must
now be manually enabled via a `-C rpath` flag.
This involved a few changes to the local build system:
* --disable-rpath is now the default configure option
* Makefiles now prefer our own LD_LIBRARY_PATH over the user's LD_LIBRARY_PATH
in order to support building rust with rust already installed.
* The compiletest program was taught to correctly pass through the aux dir as a
component of LD_LIBRARY_PATH in more situations.
The major impact of this change is that neither rustdoc nor rustc will work
out-of-the-box in all situations because they are dynamically linked. It must be
arranged to ensure that the libraries of a rust installation are part of the
LD_LIBRARY_PATH. The default installation paths for all platforms ensure this,
but if an installation is in a nonstandard location, then configuration may be
necessary.
Additionally, for all developers of rustc, it will no longer be possible to run
$target/stageN/bin/rustc out-of-the-box. The old behavior can be regained
through the `--enable-rpath` option to the configure script.
This change brings linux/mac installations in line with windows installations
where rpath is not possible.
Closes#11747
[breaking-change]
In line with what @brson, @cmr, @nikomatsakis and I discussed this morning, my
redux of the tutorial will be implemented as the Guide. This way, I can work in
small iterations, rather than dropping a huge PR, which is hard to review. In
addition, the community can observe my work as I'm doing it.
This adds a note in line with [this comment][reddit] that clarifies the state
of the tutorial, and the community's involvement with it.
[reddit]: http://www.reddit.com/r/rust/comments/28bew8/rusts_documentation_is_about_to_drastically/ci9c98k
This commit disables rustc's emission of rpath attributes into dynamic libraries
and executables by default. The functionality is still preserved, but it must
now be manually enabled via a `-C rpath` flag.
This involved a few changes to the local build system:
* --disable-rpath is now the default configure option
* Makefiles now prefer our own LD_LIBRARY_PATH over the user's LD_LIBRARY_PATH
in order to support building rust with rust already installed.
* The compiletest program was taught to correctly pass through the aux dir as a
component of LD_LIBRARY_PATH in more situations.
The major impact of this change is that neither rustdoc nor rustc will work
out-of-the-box in all situations because they are dynamically linked. It must be
arranged to ensure that the libraries of a rust installation are part of the
LD_LIBRARY_PATH. The default installation paths for all platforms ensure this,
but if an installation is in a nonstandard location, then configuration may be
necessary.
Additionally, for all developers of rustc, it will no longer be possible to run
$target/stageN/bin/rustc out-of-the-box. The old behavior can be regained
through the `--enable-rpath` option to the configure script.
This change brings linux/mac installations in line with windows installations
where rpath is not possible.
Closes#11747
[breaking-change]
Rust no longer has support for JIT compilation, so it doesn't currently
require a PaX MPROTECT exception. The extended attributes are preferred
over modifying the binaries so it's not actually going to work on most
systems like this anyway.
If JIT compilation ends up being supported again, it should handle this
by *always* applying the exception via an extended attribute without
performing auto-detection of PaX on the host. The `paxctl` tool is only
necessary with the older method involving modifying the ELF binary.
This adds a new configure option, --jemalloc-root, which will specify a location
at which libjemalloc_pic.a must live. This library is then used for the build
triple as the jemalloc library to link.
This was required to get ./configure to work on my armv7 test machine.
I haven't found anything sane to feature gate `hf` on that's pokable from the context of the configure script.
It also seems that gcc doesn't work on armv7 by default (rust wants to pass it `-m32` which isn't supported), would it be preferential to make the default `--enable-clang` on arm, or remove the `-m32` flag on that platform?
