To make progress on #18585 we're paring down the distribution to theoretically
"only libstd", and this commit makes progress on this by removing the rlibc
crate from the distribution.
The crate has now been moved into an external cargo package located in the rust
lang organization [1]. This is a breaking change due to this removal, and
existing crates depending on `rlibc` should use the Cargo crate instead.
[1]: https://github.com/rust-lang/rlibc
[breaking-change]
cc #18585
If a dylib is being produced, the compiler will now first check to see if it can
be created entirely statically before falling back to dynamic dependencies. This
behavior can be overridden with `-C prefer-dynamic`.
Due to the alteration in behavior, this is a breaking change. Any previous users
relying on dylibs implicitly maximizing dynamic dependencies should start
passing `-C prefer-dynamic` to compilations.
Closes#18499
[breaking-change]
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]
If a dylib is being produced, the compiler will now first check to see if it can
be created entirely statically before falling back to dynamic dependencies. This
behavior can be overridden with `-C prefer-dynamic`.
Due to the alteration in behavior, this is a breaking change. Any previous users
relying on dylibs implicitly maximizing dynamic dependencies should start
passing `-C prefer-dynamic` to compilations.
Closes#18499
[breaking-change]
When building for multiple targets, the initial 'make' invocation
always fails. The missing build stamp causes clean-llvm to be
invoked, but clean-llvm cleans *all* llvm builds. So what happens
is that 1) all llvm's are cleaned (a no-op), 2) llvm-${target1}
builds, 3) all llvm's are cleaned (deleting llvm-${target1}),
4) llvm-${target2} is built, 5) the remaining build for ${target1}
fails because llvm does not exist.
This makes the clean operation only clean the correct llvm build.
Should greatly reduce bot failures.
Enable parallel codegen (2 units) by default when --opt-level is 0 or 1. This
gives a minor speedup on large crates (~10%), with only a tiny slowdown (~2%)
for small ones (which usually build in under a second regardless). The current
default (no parallelization) is used when the user requests optimization
(--opt-level 2 or 3), and when the user has enabled LTO (which is incompatible
with parallel codegen).
This commit also changes the rust build system to use parallel codegen
when appropriate. This means codegen-units=4 for stage0 always, and
also for stage1 and stage2 when configured with --disable-optimize.
(Other settings use codegen-units=1 for stage1 and stage2, to get
maximum performance for release binaries.) The build system also sets
codegen-units=1 for compiletest tests (compiletest does its own
parallelization) and uses the same setting as stage2 for crate tests.
All of these crates have been deprecated for some time and properly live in the
rust-lang organization as cargo-based crates.
To update your code, depend on the rust-lang/foo repository via cargo.
[breaking-change]
When running `sudo make install`, we only want to run the actual install
as root, the building of the documentation and the distribution folder
should happen as the non-root user.
Related to #13728.
----
To reproduce issue on commit ba246100ca
it does not suffice to add just `check-build-compiletest` to
`check-secondary`; one must also ensure that `check-build-compiletest`
precedes the satisification of the `check` rule.
Otherwise hidden dependencies of `compiletest` would end up getting
satisfied when make builds `rustc` at each stage in order to
eventually run `check-stage2`.
So to handle that I moved `check-secondary` before `check` in the
`check-all` rule that bors uses, and for good measure, I also put
`check-build-compiltest` at the front of the `check-secondary` rule's
dependencies.
My understanding is that running `check-secondary` should be
relatively cheap, and thus such a reordering will not hurt bors.
----
Fix#17883.
compiletest needs to link to native crate, or at least the `rt` library.
(I tried using a dependency on `rustrt` instead, and that did not resolve the problem. But this does.)
Partially addresses #17883
The escaped newline in the middle of the variable reference breaks the
short hash substitution, leaving the link text exmpty; rewrap so that
each replacement is on its own line.
The escaped newline in the middle of the variable reference breaks the
short hash substitution, leaving the link text exmpty; rewrap so that
each replacement is on its own line.
Remove superfluous parentheses from the CTAGS_LOCATIONS expression.
Fixes the following error when executing `make TAGS.vi`:
/bin/sh: -c: line 0: syntax error near unexpected token `)'
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]
This commit removes the `librustuv` crate.
See the [runtime removal
RFC](https://github.com/rust-lang/rfcs/pull/230) for more context.
See [green-rs](https://github.com/alexcrichton/green-rs/) for a possible
migration path if you wish to continue using green-threaded I/O. The
library provides its own I/O API surface.
[breaking-change]
This makes the windows `make dist` target start producing binary tarballs, and tweaks install.sh so they work, in preparation for working on a combined Rust+Cargo installer.
