Commit Graph

153 Commits

Author SHA1 Message Date
Alex Crichton
a2434eb950 mk: Fix bootstrapping cross-hosts on beta
The beta builds are currently failing, unfortunately, due to what is presumably
some odd behavior with our makefiles. The wrong bootstrap key is being used to
generate the stage1 cross-compiled libraries, which fails the build.
Interestingly enough if the targets are directly specified as part of the build
then it works just fine! Just a bare `make` fails...

Instead of trying to understand what's happening in the makefiles instead just
tweak how we configure the bootstrap key in a way that's more likely to work.
2016-05-23 22:21:21 -07:00
Alex Crichton
02538d463a mk: Bootstrap from stable instead of snapshots
This commit removes all infrastructure from the repository for our so-called
snapshots to instead bootstrap the compiler from stable releases. Bootstrapping
from a previously stable release is a long-desired feature of distros because
they're not fans of downloading binary stage0 blobs from us. Additionally, this
makes our own CI easier as we can decommission all of the snapshot builders and
start having a regular cadence to when we update the stage0 compiler.

A new `src/etc/get-stage0.py` script was added which shares some code with
`src/bootstrap/bootstrap.py` to read a new file, `src/stage0.txt`, which lists
the current stage0 compiler as well as cargo that we bootstrap from. This script
will download the relevant `rustc` package an unpack it into `$target/stage0` as
we do today.

One problem of bootstrapping from stable releases is that we're not able to
compile unstable code (e.g. all the `#![feature]` directives in libcore/libstd).
To overcome this we employ two strategies:

* The bootstrap key of the previous compiler is hardcoded into `src/stage0.txt`
  (enabled as a result of ) and exported by the build system. This enables
  nightly features in the compiler we download.
* The standard library and compiler are pinned to a specific stage0, which
  doesn't change, so we're guaranteed that we'll continue compiling as we start
  from a known fixed source.

The process for making a release will also need to be tweaked now to continue to
cadence of bootstrapping from the previous release. This process looks like:

1. Merge `beta` to `stable`
2. Produce a new stable compiler.
3. Change `master` to bootstrap from this new stable compiler.
4. Merge `master` to `beta`
5. Produce a new beta compiler
6. Change `master` to bootstrap from this new beta compiler.

Step 3 above should involve very few changes as `master` was previously
bootstrapping from `beta` which is the same as `stable` at that point in time.
Step 6, however, is where we benefit from removing lots of `#[cfg(stage0)]` and
get to use new features. This also shouldn't slow the release too much as steps
1-5 requires little work other than waiting and step 6 just needs to happen at
some point during a release cycle, it's not time sensitive.

Closes 
Closes 
2016-04-19 10:56:49 -07:00
Alex Crichton
6908e4e10d mk: Add -C metadata for compiling crates we ship
This should re-enable all external builds of crates with the same name. Right
now Cargo doesn't pass `-C metadata` for the top-level library being compiled,
so if that library is called `libc`, for example, then it won't be able to link
to the standard library which *also* has a `libc` library compiled without `-C
metadata`. This can result in naming conflicts which need to be resolved.

By passing `-C metadata` to the in-tree crates we ship it should add some extra
salt to all symbol names to ensure that they don't collide.
2016-03-28 09:19:25 -07:00
Alex Crichton
b980f22877 mk: Move disable-jemalloc logic into makefiles
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.
2016-02-25 21:05:59 -08:00
Alex Crichton
178d4b0fd3 Revert "mk: fix some undefined variable warnings"
This reverts commit d03712977d.
2016-02-01 23:27:04 -08:00
Tamir Duberstein
d03712977d mk: fix some undefined variable warnings
Some of this is scary stuff. Probably time to lint against this.

Found with `make --warn-undefined-variables`.
2016-02-01 05:21:06 -05:00
Alex Crichton
2273b52023 mk: Move from -D warnings to #![deny(warnings)]
This commit removes the `-D warnings` flag being passed through the makefiles to
all crates to instead be a crate attribute. We want these attributes always
applied for all our standard builds, and this is more amenable to Cargo-based
builds as well.

Note that all `deny(warnings)` attributes are gated with a `cfg(stage0)`
attribute currently to match the same semantics we have today
2016-01-24 20:35:55 -08:00
Sébastien Marie
e6418964b9 remove specific code for OpenBSD that define STDCPP_LIBDIR_RUSTFLAGS
it isn't the good way to process, as it makes conflicts when building rustc while another version of rustc in installed system-wide.
2015-12-20 07:21:36 +01:00
Richard Diamond
7bd69f2248 Better support for --llvm-root.
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).
2015-12-13 15:05:43 -06:00
Felix S. Klock II
31d383fcd2 Remove STARTUP_OBJS from Makefile deps for non win-gnu targets.
The `rsbegin.o` and `rsend.o` build products should not be generated
on non WinGnu platforms.

This is another path to resolving  for non win-gnu targets.
(And it won't require a snapshot, unlike PR #30208.)
2015-12-08 14:56:22 +01:00
bors
4bd302ee9f Auto merge of - semarie:openbsd-stdcpp-path, r=alexcrichton
under openbsd, the library path of libstdc++ need to be explicit (due
to the fact the default linker `cc` is gcc-4.2, and not gcc-4.9).

but when a recent LLVM is installed, rustc compilation pikes the bad
LLVM version (which live in /usr/local/lib, which is same directory of
libestdc++.so for gcc-4.9).

this patch move the libstdc++ path from RUST_FLAGS_<target> to special
variable, and use it *after* LLVM_LIBDIR_RUSTFLAGS_<target> in
arguments.

r? @alexcrichton
2015-11-17 02:21:20 +00:00
William Throwe
a0e10b249e Clean up some "suspicious" whitespace in target.mk
Emacs warns that makefile lines that start with spaces followed by
tabs are "suspicious".  These were harmless since they were
continuation lines, but getting rid of the warning is nice and this
version looks better.
2015-11-13 15:15:51 -05:00
Sébastien Marie
646b0b6392 pass stdc++ library path after LVVM library path
under openbsd, the library path of libstdc++ need to be explicit (due
to the fact the default linker `cc` is gcc-4.2, and not gcc-4.9).

but when a recent LLVM is installed, rustc compilation pikes the bad
LLVM version (which live in /usr/local/lib, which is same directory of
libestdc++.so for gcc-4.9).

this patch move the libstdc++ path from RUST_FLAGS_<target> to special
variable, and use it *after* LLVM_LIBDIR_RUSTFLAGS_<target> in
arguments.
2015-11-11 20:16:17 +01:00
Vadim Chugunov
9f9afe5769 Make sure rsbegin.o and rsend.o get packaged with target lib artifacts.
Also, unified libc startup objects finding logic with that of the `-musl` target, since conceptually they were doing the same thing.
2015-11-07 17:56:55 -08:00
Vadim Chugunov
9a71c5c331 Use gcc -print-file-name for finding C runtime startup objects:
reverted changes in configure, refactored target.mk
2015-10-21 10:05:19 -07:00
Vadim Chugunov
bd0cf1ba13 Don't use GCC's startup objects (crtbegin.o/crtend.o); build and use our own (for now on for -windows-gnu target only).
Since it isn't possible to disable linkage of just GCC startup objects, we now need logic for finding libc installation directory and copying the required startup files (e.g. crt2.o) to rustlib directory.
Bonus change: use the `-nodefaultlibs` flag on Windows, thus paving the way to direct linker invocation.
2015-10-19 00:42:04 -07:00
Niko Matsakis
9b45874445 plumbing to automatically run MIR for crates where it works;
this serves as a poor man's unit test infrastructure until
MIR is more built up
2015-09-06 07:27:23 -04:00
Marc-Antoine Perennou
c977596992 rustc_back: add configure options for default linker and ar
Signed-off-by: Marc-Antoine Perennou <Marc-Antoine@Perennou.com>
2015-08-19 18:06:34 +02:00
Alex Crichton
938099a7eb Register new snapshots
* Lots of core prelude imports removed
* Makefile support for MSVC env vars and Rust crates removed
* Makefile support for morestack removed
2015-08-11 15:11:13 -07:00
bors
23f43896ce Auto merge of - alexcrichton:msvc-builtin-llvm-ar, r=huonw
This means that we no longer need to ship the `llvm-ar.exe` binary in the MSVC
distribution, and after a snapshot we can remove a good bit of logic from the
makefiles!
2015-08-11 07:48:39 +00:00
Alex Crichton
e648c96c5f trans: Stop informing LLVM about dllexport
Rust's current compilation model makes it impossible on Windows to generate one
object file with a complete and final set of dllexport annotations. This is
because when an object is generated the compiler doesn't actually know if it
will later be included in a dynamic library or not. The compiler works around
this today by flagging *everything* as dllexport, but this has the drawback of
exposing too much.

Thankfully there are alternate methods of specifying the exported surface area
of a dll on Windows, one of which is passing a `*.def` file to the linker which
lists all public symbols of the dynamic library. This commit removes all
locations that add `dllexport` to LLVM variables and instead dynamically
generates a `*.def` file which is passed to the linker. This file will include
all the public symbols of the current object file as well as all upstream
libraries, and the crucial aspect is that it's only used when generating a
dynamic library. When generating an executable this file isn't generated, so all
the symbols aren't exported from an executable.

To ensure that statically included native libraries are reexported correctly,
the previously added support for the `#[linked_from]` attribute is used to
determine the set of FFI symbols that are exported from a dynamic library, and
this is required to get the compiler to link correctly.
2015-08-10 18:20:42 -07:00
Alex Crichton
138252cc6a trans: Specify archive_format for MSVC
This means that we no longer need to ship the `llvm-ar.exe` binary in the MSVC
distribution, and after a snapshot we can remove a good bit of logic from the
makefiles!
2015-08-10 17:45:16 -07:00
Alex Crichton
7a3fdfbf67 Remove morestack support
This commit removes all morestack support from the compiler which entails:

* Segmented stacks are no longer emitted in codegen.
* We no longer build or distribute libmorestack.a
* The `stack_exhausted` lang item is no longer required

The only current use of the segmented stack support in LLVM is to detect stack
overflow. This is no longer really required, however, because we already have
guard pages for all threads and registered signal handlers watching for a
segfault on those pages (to print out a stack overflow message). Additionally,
major platforms (aka Windows) already don't use morestack.

This means that Rust is by default less likely to catch stack overflows because
if a function takes up more than one page of stack space it won't hit the guard
page. This is what the purpose of morestack was (to catch this case), but it's
better served with stack probes which have more cross platform support and no
runtime support necessary. Until LLVM supports this for all platform it looks
like morestack isn't really buying us much.

cc  (still need stack probes)
Closes  (a drive-by fix to help diagnostics on stack overflow)
2015-08-10 16:35:44 -07:00
Alex Crichton
91c22b6302 msvc: Lookup linker in windows registry
This commit alters the compiler to no longer "just run link.exe" but instead
probe the system's registry to find where the linker is located. The default
library search path (normally found through LIB) is also found through the
registry. This also brings us in line with the default behavior of Clang, and
much of the logic of where to look for information is copied over from Clang as
well. Finally, this commit removes the makefile logic for updating the
environment variables for the compiler, except for stage0 where it's still
necessary.

The motivation for this change is rooted in two positions:

* Not having to set up these environment variables is much less hassle both for
  the bootstrap and for running the compiler itself. This means that the
  compiler can be run outside of VS shells and be run inside of cmd.exe or a
  MSYS shell.

* When dealing with cross compilation, there's not actually a set of environment
  variables that can be set for the compiler. This means, for example, if a
  Cargo compilation is targeting 32-bit from 64-bit you can't actually set up
  one set of environment variables. Having the compiler deal with the logic
  instead is generally much more convenient!
2015-07-01 09:35:55 -07:00
Alex Crichton
ae36d4f72a mk: Add support for i686-pc-windows-msvc
This commit modifies the configure script and our makefiles to support building
32-bit MSVC targets. The MSVC toolchain is now parameterized over whether it can
produce a 32-bit or 64-bit binary. The configure script was updated to export
more variables at configure time, and the makefiles were rejiggered to
selectively reexport the relevant environment variables for the applicable
targets they're going to run for.
2015-06-27 13:02:18 -07:00
Alex Crichton
b8c59211ed mk: Fix MSVC bootstrapping itself
Now that MSVC support has landed in the most recent nightlies we can now have
MSVC bootstrap itself without going through a GNU compiler first. Unfortunately,
however, the bootstrap currently fails due to the compiler not being able to
find the llvm-ar.exe tool during the stage0 libcore compile. The compiler cannot
find this tool because it's looking inside a directory that does not exist:

    $SYSROOT/rustlib/x86_64-pc-windows-gnu/bin

The `gnu` on this triple is because the bootstrap compiler's host architecture
is GNU. The build system, however, only arranges for the llvm-ar.exe tool to be
available in this location:

    $SYSROOT/rustlib/x86_64-pc-windows-msvc/bin

To resolve this discrepancy, the build system has been modified to understand
triples that are bootstrapped from another triple, and in this case copy the
native tools to the right location.
2015-05-27 19:36:28 -07:00
Alex Crichton
b538189ba0 mk: Generate a .def file for rustc_llvm on MSVC
Windows needs explicit exports of functions from DLLs but LLVM does not mention
any of its symbols as being export-able from a DLL. The compiler, however,
relies on being able to use LLVM symbols across DLL boundaries so we need to
force many of LLVM's symbols to be exported from `rustc_llvm.dll`. This commit
adds support for generation of a `rustc_llvm.def` file which is passed along to
the linker when generating `rustc_llvm.dll` which should keep all these symbols
exportable and usable.
2015-05-19 10:53:07 -07:00
Alex Crichton
a4ef308473 mk: Add the ability to depend on native LLVM tools
The compiler will require that `llvm-ar.exe` be available for MSVC-targeting
builds (more comments on this soon), so this commit adds support for targets to
depend on LLVM tools. The `core` library for MSVC depends on `llvm-ar.exe` which
will be copied into place for the target before the compiler starts to run.

Note that these targets all depend on `llvm-config.exe` to ensure that they're
built before they're attempted to be copied.
2015-05-19 10:53:04 -07:00
Alex Crichton
ee258c548f mk: Fix native LLVM deps for cross-host builds
We use a script called `mklldeps.py` to run `llvm-config` to generate a list
of LLVM libraries and native dependencies needed by LLVM, but all cross-compiled
LLVM builds were using the *host triple's* `llvm-config` instead of the
*target's* `llvm-config`. This commit alters this to require the right
`llvmdeps.rs` to be generated which will run the correct `llvm-config`.
2015-05-19 10:36:00 -07:00
Alex Crichton
cd980b3bee mk: Add support for musl-based builds
This commit adds support to the makefiles, configuration script, and build
system to understand MUSL. This is broken up into a few parts:

* Any target of the form `*-musl` requires the `--musl-root` option to
  `./configure` which will indicate the root of the MUSL installation. It is
  also expected that there is a libunwind build inside of that installation
  built against that MUSL.

* Objects from MUSL are copied into the build tree for Rust to be statically
  linked into the appropriate Rust library.

* Objects for binary startup and shutdown are included in each Rust installation
  by default for MUSL. This requires MUSL to only be installed on the machine
  compiling rust. Only a linker will be necessary for compiling against MUSL on
  a target machine.

Eventually a MUSL and/or libunwind build may be integrated by default into the
build but for now they are just always assumed to exist externally.
2015-04-27 10:11:15 -07:00
Vadim Petrochenkov
1accaa9f86 Fix some typos 2015-03-28 18:09:51 +03:00
Ryan Prichard
b07a1dfcd1 Fix the Linux nightly build by adding a LLVM_CONFIG_<target-triple> dep.
The RUST_TARGET_STAGE_N rule uses LLVM_LIBDIR_RUSTFLAGS_<target-triple>,
which expands to -L "$(llvm-config --libdir)" when the target-triple is
also a host-triple. Rather than expand to -L "" if llvm-config has not yet
been built, add a dependency on the target llvm-config.

When the target-triple is not a host-triple, the new LLVM_CONFIG_$(2)
dependency should expand to nothing.
2015-03-16 21:13:36 -07:00
Ryan Prichard
00211ecfda Avoid passing -L "" during cross-compilation.
LLVM_LIBDIR_<triple> is only defined for host triples, not target triples.

FWIW, the same is true for LLVM_STDCPP_RUSTFLAGS_<triple>, where we
explicitly define it as empty when --enable-llvm-static-stdcpp is not
specified, but it's still undefined for cross-compiled triples.
2015-03-13 16:46:45 -07:00
Ryan Prichard
de52403295 Avoid passing -L "" to rustc.
Currently, target.mk passes -L "" when LLVM_STDCPP_LOCATION_$(2) is empty.

This fixes .
2015-03-12 04:09:12 -07:00
Felix S. Klock II
62aa899e3d Make build timestamp files robust in face of concurrent source modification.
Strategy: If the end goal is to touch e.g. `stamp.std`, then we first
touch `stamp.std.start_time` before doing anything else.  Then when
the receipe finishes, we touch `stamp.std` using the timestamp from
`stamp.std.start_time` as the reference time, and remove
`stamp.std.start_time`.

Fix .
2015-03-03 15:11:01 +01:00
Alex Crichton
1d4ce37946 mk: Use host llvm linkage paths, not target ones
We only build LLVM for the host architecture, not the target architecture, so
this was just a minor typo in the parameters uses.

Closes 
2014-11-30 00:01:19 -08:00
Richard Diamond
80d520fcf2 Don't use the same llvmdeps.rs for every host. 2014-11-25 17:28:49 -06:00
Cody P Schafer
29cc7c2adf mk/target: fix typo so we depend on the correct directory
Without this, if we we're using a non-standard host libdir, the target
bindir would not exist (and rustc would fail to write to the
non-existent directory).
2014-11-20 16:00:12 -05:00
Alex Crichton
3036b00127 rustc: Default to static linking dylibs
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 
[breaking-change]
2014-11-03 15:08:20 -08:00
Birunthan Mohanathas
6511053d1c mk: Add space before line continuation backslash 2014-07-23 08:44:11 -07:00
Birunthan Mohanathas
c5433c3a0f mk: Remove extra whitespace before line continuation backslashes 2014-07-23 08:41:55 -07:00
Brian Anderson
d3096c2348 Move llvm bindings to their own crate 2014-07-14 12:27:07 -07:00
Alex Crichton
0c71e0c596 Register new snapshots
Closes 
2014-07-09 10:57:58 -07:00
Alex Crichton
6d4d83c94d mk: Fix bootstrapping the nightly builds
The stage0 compiler for a non-CFG_BUILD architecture needs to have the new
`-C extra-filename` argument passed.
2014-07-06 08:28:06 -07:00
Alex Crichton
df4ea9c39a rustc: Stop putting hashes in filenames by default
The compiler will no longer insert a hash or version into a filename by default.
Instead, all output is simply based off the crate name being compiled. For
example, a crate name of `foo` would produce the following outputs:

* bin => foo
* rlib => libfoo.rlib
* dylib => libfoo.{so,dylib} or foo.dll
* staticlib => libfoo.a

The old behavior has been moved behind a new codegen flag,
`-C extra-filename=<hash>`. For example, with the "extra filename" of `bar` and
a crate name of `foo`, the following outputs would be generated:

* bin => foo (same old behavior)
* rlib => libfoobar.rlib
* dylib => libfoobar.{so,dylib} or foobar.dll
* staticlib => libfoobar.a

The makefiles have been altered to pass a hash by default to invocations of
`rustc` so all installed rust libraries will have a hash in their filename. This
is done because the standard libraries are intended to be installed into
privileged directories such as /usr/local. Additionally, it involves very few
build system changes!

RFC: 0035-remove-crate-id
[breaking-change]
2014-07-05 12:45:42 -07:00
Alex Crichton
4cd932f94e alloc: Allow disabling jemalloc 2014-06-16 18:15:48 -07:00
Brian Anderson
7c8c544731 mk: Replace 'oxidize' with 'rustc'. Closes 2014-05-21 11:01:59 -07:00
Alex Crichton
acdee8b904 llvm: Add an option to statically link libstdc++
The goal of the snapshot bots is to produce binaries which can run in as many
locations as possible. Currently we build on Centos 6 for this reason, but with
LLVM's update to C++11, this reduces the number of platforms that we could
possibly run on.

This adds a --enable-llvm-static-stdcpp option to the ./configure script for
Rust which will enable building a librustc with a static dependence on
libstdc++. This normally isn't necessary, but this option can be used on the
snapshot builders in order to continue to make binaries which should be able to
run in as many locations as possible.
2014-04-17 11:39:51 -07:00
Brian Anderson
d252539990 mk: Rename CFG_COMPILER to CFG_COMPILER_HOST_TRIPLE
Much clearer
2014-03-25 21:35:10 -07:00
Vadim Chugunov
b7651325eb Build compiler-rt and link it to all crates, similarly to morestack. 2014-02-11 15:59:59 -08:00