Commit graph

674 commits

Author SHA1 Message Date
Doug Goldstein
e39c8d6dc8
configure: only req CMake if we're building LLVM
CMake is only necessary if LLVM is going to be built and not in any
other case.

Signed-off-by: Doug Goldstein <cardoe@cardoe.com>
2016-12-02 11:22:57 -06:00
Brian Anderson
295148862a configure: Fix string equality 2016-11-21 22:11:20 +00:00
bors
b1da18fe9b Auto merge of #37822 - cuviper:llvm-link-shared, r=alexcrichton
rustbuild: allow dynamically linking LLVM

The makefiles and `mklldeps.py` called `llvm-config --shared-mode` to
find out if LLVM defaulted to shared or static libraries, and just went
with that.  But under rustbuild, `librustc_llvm/build.rs` was assuming
that LLVM should be static, and even forcing `--link-static` for 3.9+.

Now that build script also uses `--shared-mode` to learn the default,
which should work better for pre-3.9 configured for dynamic linking, as
it wasn't possible back then to choose differently via `llvm-config`.

Further, the configure script now has a new `--enable-llvm-link-shared`
option, which allows one to manually override `--link-shared` on 3.9+
instead of forcing static.

Update: There are now four static/shared scenarios that can happen
for the supported LLVM versions:

- 3.9+: By default use `llvm-config --link-static`
- 3.9+ and `--enable-llvm-link-shared`: Use `--link-shared` instead.
- 3.8: Use `llvm-config --shared-mode` and go with its answer.
- 3.7: Just assume static, maintaining the status quo.
2016-11-19 08:08:26 -08:00
Josh Stone
f13391a603 rustbuild: allow dynamically linking LLVM
The makefiles and `mklldeps.py` called `llvm-config --shared-mode` to
find out if LLVM defaulted to shared or static libraries, and just went
with that.  But under rustbuild, `librustc_llvm/build.rs` was assuming
that LLVM should be static, and even forcing `--link-static` for 3.9+.

Now that build script also uses `--shared-mode` to learn the default,
which should work better for pre-3.9 configured for dynamic linking, as
it wasn't possible back then to choose differently via `llvm-config`.

Further, the configure script now has a new `--enable-llvm-link-shared`
option, which allows one to manually override `--link-shared` on 3.9+
instead of forcing static.
2016-11-16 23:28:14 -08:00
bors
6cd5be81cc Auto merge of #37607 - dns2utf8:doc_grammar, r=alexcrichton
Fix grammar verification

 * Use make check-lexer to verify the grammar.
 * Extend grammar/README
 * Add make clean-grammar rule
 * Add target check-build-lexer-verifier to make tidy, so it will build the verifier with every build and catch future errors

This is the continuation of #34994

r? @steveklabnik @jonathandturner @alexcrichton
2016-11-16 21:02:55 -08:00
Stefan Schindler
0e1828ab03 Fix grammar verification
* Use `make check-lexer` to verify the grammar.
 * Extend grammar/README
 * Add make clean-grammar rule
 * Add target `check-build-lexer-verifier` to `make tidy`, so it will build the verifier with every build and catch future errors
 * Search for antlr4 with configure and find
2016-11-16 22:42:07 +01:00
bors
43006fcea0 Auto merge of #37742 - mrhota:llvm_debuginfo, r=alexcrichton
Add llvm debuginfo configure option

CC @nnethercote @Mark-Simulacrum

We add a new configure option, `--enable-llvm-debuginfo`, to do exactly what you'd think.

Re: #31033

Fixes #37738
2016-11-15 09:10:23 -08:00
A.J. Gardner
d3574b8dc7 Make LLVM debuginfo option names consistent 2016-11-13 12:38:10 -06:00
A.J. Gardner
7a91d4a25b Add llvm debuginfo configure option 2016-11-12 19:14:51 -06:00
Jorge Aparicio
4f9f7b014e also enable the MSP430 backend in Makefiles 2016-11-12 17:33:35 -05:00
Alex Crichton
31a8638e5e rustbuild: Tweak for vendored dependencies
A few changes are included here:

* The `winapi` and `url` dependencies were dropped. The source code for these
  projects is pretty weighty, and we're about to vendor them, so let's not
  commit to that intake just yet. If necessary we can vendor them later but for
  now it shouldn't be necessary.

* The `--frozen` flag is now always passed to Cargo, obviating the need for
  tidy's `cargo_lock` check.

* Tidy was updated to not check the vendor directory

Closes #34687
2016-11-08 07:32:05 -08:00
Alex Crichton
18ee04b3df Merge branch 'gdb-next-gen' of https://github.com/TimNN/rust into rollup 2016-11-05 10:51:34 -07:00
Jonathan Turner
d2f4a9d7be Rollup merge of #37488 - frewsxcv:quiet-travis, r=alexcrichton
Use quieter test output when running tests on Travis CI.

Fixes https://github.com/rust-lang/rust/issues/36788.
2016-11-02 15:09:41 -04:00
Tim Neumann
dce460028e detect gdb version & rust support in compiletest 2016-10-31 21:12:59 +01:00
Corey Farwell
c8c6d2c732 Use quieter test output when running tests on Travis CI.
Fixes https://github.com/rust-lang/rust/issues/36788.
2016-10-30 17:31:17 -04:00
Matwey V. Kornilov
9b81f3c81b Add armv6l autodetection
Use arm-unknown-linux-gnueabihf for hardware floating point armv6 variant
2016-10-30 11:27:58 +03:00
Matwey V. Kornilov
10ce90fca2 Fix armv7 autodetection
armv7l is armv7 architecture and CFG_CPUTYPE should be armv7 in order to end up
with armv7-unknown-linux-gnueabihf.mk rather than
arm-unknown-linux-gnueabihf.mk
2016-10-30 11:26:25 +03:00
Alex Crichton
f96a4cca81 configure: Disable debuginfo lines on MinGW
Looks like these are causing assertions on the bots, let's disable them for now
(#37364).
2016-10-23 10:25:01 -07:00
Alex Crichton
803576c17e Enable line number debuginfo in releases
This commit enables by default passing the `-C debuginfo=1` argument to the
compiler for the stable, beta, and nightly release channels. A new configure
option was also added, `--enable-debuginfo-lines`, to enable this behavior in
developer builds as well.

Closes #36452
2016-10-19 10:08:05 -07:00
Alex Crichton
81494843b0 Rollup merge of #37091 - alexcrichton:configure, r=brson
configure: Fix gcc detection for LLVM

We have a case where 32-bit compilation accidentally requested clang when gcc
was the only one available.
2016-10-12 14:07:56 -07:00
Alex Crichton
62861f8797 configure: Fix gcc detection for LLVM
We have a case where 32-bit compilation accidentally requested clang when gcc
was the only one available.
2016-10-11 10:08:07 -07:00
bors
e33562078f Auto merge of #36983 - alexcrichton:configure-multiple-musl, r=brson
configure: Add options for separate musl roots

This allows using the `./configure` script to enable rustbuild to compile
multiple musl targets at once. We'll hopefully use this soon on our bots to
produce a bunch of targets.
2016-10-11 04:26:56 -07:00
Brian Anderson
5388d3fbe8 Turn on JSBackend in the makefiles 2016-10-06 19:02:28 +00:00
Alex Crichton
19d192920b configure: Add options for separate musl roots
This allows using the `./configure` script to enable rustbuild to compile
multiple musl targets at once. We'll hopefully use this soon on our bots to
produce a bunch of targets.
2016-10-05 11:00:55 -07:00
Jonathan Turner
47a335b677 Rollup merge of #36803 - brson:node, r=alexcrichton
Move nodejs detection into bootstrap

This avoids issues with mingw path conversions.

r? @alexcrichton
2016-09-28 20:21:52 -07:00
Brian Anderson
27588dd7a1 Move nodejs detection into bootstrap
This avoids issues with mingw path conversions.
2016-09-28 09:05:19 -07:00
Niels Sascha Reedijk
01fecb9f8f Haiku: add support for building on Haiku
* Hand rebased from Niels original work on 1.9.0
2016-09-25 11:15:18 -05:00
Guillaume Gomez
677ede2623 Rollup merge of #36500 - orbea:docdir, r=nikomatsakis
This installs documentation not man pages

This fixes the description for docdir in configure, it was my mistake for leaving it as "man pages", oops.
2016-09-24 00:15:45 +02:00
orbea
b19c9ec054 This installs documentation not man pages 2016-09-15 10:26:16 -07:00
bors
00ce2c0ffa Auto merge of #36360 - orbea:docdir, r=alexcrichton
Allow setting --docdir

This will allow setting `--docdir` during configure, this is useful because not all linux distributions install documentation to `/usr/share/doc`.  For example in Slackware documentation is installed to `/usr/doc/$PRGNAM-$VERSION` and `/usr/share/doc` is a symlink to `/usr/doc`.

To use this `./configure --docdir=/usr/doc/$PRGNAM-$VERSION` can be used.
2016-09-12 01:33:40 -07:00
bors
4812cf392f Auto merge of #36369 - uweigand:s390x, r=alexcrichton
Add s390x support

This adds support for building the Rust compiler and standard
library for s390x-linux, allowing a full cross-bootstrap sequence
to complete.  This includes:

- Makefile/configure changes to allow native s390x builds
- Full Rust compiler support for the s390x C ABI
  (only the non-vector ABI is supported at this point)
- Port of the standard library to s390x
- Update the liblibc submodule to a version including s390x support
- Testsuite fixes to allow clean "make check" on s390x

Caveats:

- Resets base cpu to "z10" to bring support in sync with the default
  behaviour of other compilers on the platforms.  (Usually, upstream
  supports all older processors; a distribution build may then chose
  to require a more recent base version.)  (Also, using zEC12 causes
  failures in the valgrind tests since valgrind doesn't fully support
  this CPU yet.)

- z13 vector ABI is not yet supported.  To ensure compatible code
  generation, the -vector feature is passed to LLVM.  Note that this
  means that even when compiling for z13, no vector instructions
  will be used.  In the future, support for the vector ABI should be
  added (this will require common code support for different ABIs
  that need different data_layout strings on the same platform).

- Two test cases are (temporarily) ignored on s390x to allow passing
  the test suite.  The underlying issues still need to be fixed:
  * debuginfo/simd.rs fails because of incorrect debug information.
    This seems to be a LLVM bug (also seen with C code).
  * run-pass/union/union-basic.rs simply seems to be incorrect for
    all big-endian platforms.

Signed-off-by: Ulrich Weigand <ulrich.weigand@de.ibm.com>
2016-09-11 10:53:24 -07:00
Ulrich Weigand
19b84088d7 Add s390x support
This adds support for building the Rust compiler and standard
library for s390x-linux, allowing a full cross-bootstrap sequence
to complete.  This includes:

- Makefile/configure changes to allow native s390x builds
- Full Rust compiler support for the s390x C ABI
  (only the non-vector ABI is supported at this point)
- Port of the standard library to s390x
- Update the liblibc submodule to a version including s390x support
- Testsuite fixes to allow clean "make check" on s390x

Caveats:

- Resets base cpu to "z10" to bring support in sync with the default
  behaviour of other compilers on the platforms.  (Usually, upstream
  supports all older processors; a distribution build may then chose
  to require a more recent base version.)  (Also, using zEC12 causes
  failures in the valgrind tests since valgrind doesn't fully support
  this CPU yet.)

- z13 vector ABI is not yet supported.  To ensure compatible code
  generation, the -vector feature is passed to LLVM.  Note that this
  means that even when compiling for z13, no vector instructions
  will be used.  In the future, support for the vector ABI should be
  added (this will require common code support for different ABIs
  that need different data_layout strings on the same platform).

- Two test cases are (temporarily) ignored on s390x to allow passing
  the test suite.  The underlying issues still need to be fixed:
  * debuginfo/simd.rs fails because of incorrect debug information.
    This seems to be a LLVM bug (also seen with C code).
  * run-pass/union/union-basic.rs simply seems to be incorrect for
    all big-endian platforms.

Signed-off-by: Ulrich Weigand <ulrich.weigand@de.ibm.com>
2016-09-09 22:28:19 +01:00
bors
1284081d33 Auto merge of #36256 - rjgoldsborough:make-configure-detect-nodejs-36207, r=alexcrichton
adding a check to bootstrap script

and a check to the rust config script

refs #36207

first crack at making configure detect nodejs
2016-09-09 14:04:31 -07:00
orbea
5e9149d73f Allow setting --docdir 2016-09-08 23:18:20 -07:00
Jake Goldsborough
0adcf46cdf detecting nodejs in configure 2016-09-06 18:31:00 -07:00
bors
2dbf600d15 Auto merge of #36242 - semarie:local-rebuild, r=alexcrichton
Use libraries from local-rust-root directory in configure when using …

…--enable-local-rebuild

When using --enable-local-rebuild configure options, the configure
script will test rustc version. But when running it, it will not use the
libraries in the local-rust-root directory.

So use `LD_LIBRARY_PATH` environment variable to correct it.

Under OpenBSD, we use `--enable-local-rebuild` for rebuilding rustc-1.11.0 using rustc-1.11.0. But as it is in use in -current (the developpment branch of OpenBSD), system libraries could easily have ABI/API changes. The (unofficial) bootstrap (rustc-1.11.0 used for building rustc-1.11.0) include several system libraries to permit it to run. The build system use libraries in stage0/lib directory. But the configure script doesn't.

Due to my special use of `--enable-local-rebuild`, I dunno if this PR is suitable for inclusion. But it corrects a difference between build and configure use of the binary.

r? @alexcrichton
2016-09-04 23:50:04 -07:00
bors
b7d19899de Auto merge of #36034 - ahmedcharles:orbit, r=eddyb
Remove --{enable|disable}-orbit from configure.

Fixes #35956.

r? @eddyb

There are only two buildbots left, though they are both failing. Is there something to be done there other than wait?
2016-09-03 23:24:32 -07:00
Sébastien Marie
92aa7e4252 Use libraries from local-rust-root directory in configure when using --enable-local-rebuild
When using --enable-local-rebuild configure options, the configure
script will test rustc version. But when running it, it will not use the
libraries in the local-rust-root directory.

So use `LD_LIBRARY_PATH` environment variable to correct it.
2016-09-03 14:10:41 +02:00
Ahmed Charles
cd8f0aa7f2 Remove --{enable|disable}-orbit from configure.
Fixes #35956.
2016-09-02 01:57:31 -07:00
Mohit Agarwal
7d5fa9edc9
configure: check if any of the arguments contain --help
Currently it checks only the first argument.

Fixes #31216
2016-09-01 18:49:35 +05:30
Jorge Aparicio
15d8dfb6a0 build llvm with systemz backend enabled, and link to related libraries
when building rust against system llvm

closes #36077
2016-08-28 13:18:28 -05:00
Eduard Burtescu
cb9b0ed91b Disable old trans access via -Z orbit, #[rustc_no_mir] or --disable-orbit. 2016-08-24 13:23:37 +03:00
Jake Goulding
b707a12a6b Allow compiling against a custom LLVM 3.9 installation 2016-08-11 12:55:53 -04:00
Eduard Burtescu
90ba77a7a9 Make --enable-orbit the default in ./configure. 2016-08-02 09:01:47 +03:00
bors
2c1612c62a Auto merge of #34743 - badboy:llvm-upgrade, r=eddyb
LLVM upgrade

As discussed in https://internals.rust-lang.org/t/need-help-with-emscripten-port/3154/46 I'm trying to update the used LLVM checkout in Rust.

I basically took @shepmaster's code and applied it on top (though I did the commits manually, the [original commits have better descriptions](https://github.com/rust-lang/rust/compare/master...avr-rust:avr-support).

With these changes I was able to build rustc. `make check` throws one last error on `run-pass/issue-28950.rs`. Output: https://gist.github.com/badboy/bcdd3bbde260860b6159aa49070a9052

I took the metadata changes as is and they seem to work, though it now uses the module in another step. I'm not sure if this is the best and correct way.

Things to do:

* [x] ~~Make `run-pass/issue-28950.rs` pass~~ unrelated
* [x] Find out how the `PositionIndependentExecutable` setting is now used
* [x] Is the `llvm::legacy` still the right way to do these things?

cc @brson @alexcrichton
2016-08-01 04:47:48 -07:00
Timon Van Overveldt
f7247d1071 Add ARM MUSL targets.
The targets are:
- `arm-unknown-linux-musleabi`
- `arm-unknown-linux-musleabihf`
- `armv7-unknown-linux-musleabihf`

These mirror the existing `gnueabi` targets.

All of these targets produce fully static binaries, similar to the
x86 MUSL targets.

For now these targets can only be used with `--rustbuild` builds, as
https://github.com/rust-lang/compiler-rt/pull/22 only made the
necessary compiler-rt changes in the CMake configs, not the plain
GNU Make configs.

I've tested these targets GCC 5.3.0 compiled again musl-1.1.12
(downloaded from http://musl.codu.org/). An example `./configure`
invocation is:

```
./configure \
    --enable-rustbuild
    --target=arm-unknown-linux-musleabi \
    --musl-root="$MUSL_ROOT"
```

where `MUSL_ROOT` points to the `arm-linux-musleabi` prefix.
Usually that path will be of the form
`/foobar/arm-linux-musleabi/arm-linux-musleabi`.

Usually the cross-compile toolchain will live under
`/foobar/arm-linux-musleabi/bin`. That path should either by added
to your `PATH` variable, or you should add a section to your
`config.toml` as follows:

```
[target.arm-unknown-linux-musleabi]
cc = "/foobar/arm-linux-musleabi/bin/arm-linux-musleabi-gcc"
cxx = "/foobar/arm-linux-musleabi/bin/arm-linux-musleabi-g++"
```

As a prerequisite you'll also have to put a cross-compiled static
`libunwind.a` library in `$MUSL_ROOT/lib`. This is similar to [how
the x86_64 MUSL targets are built]
(https://doc.rust-lang.org/book/advanced-linking.html).
2016-07-30 15:39:13 -05:00
Alex Crichton
d851428cc3 configure: Fix grep invocation for llvm-mc argument 2016-07-29 10:29:44 +02:00
Jan-Erik Rediger
dc7076b52e [LLVM-3.9] Pass correct relocation model flag 2016-07-29 10:29:44 +02:00
bors
34d7f7e607 Auto merge of #34606 - mathstuf:llvm-with-ninja, r=alexcrichton
llvm, rt: build using the Ninja generator if available

The Ninja generator generally builds much faster than make. It may also
be used on Windows to have a vast speed improvement over the Visual
Studio generators.

Currently hidden behind an `--enable-ninja` flag because it does not
obey the top-level `-j` or `-l` flags given to `make`.
2016-07-16 21:09:15 -07:00
Ximin Luo
c850470f73 mk: If local-rust is the same as the current version, then force a local-rebuild 2016-07-15 19:37:15 +02:00
bors
3265bd54b5 Auto merge of #33971 - bltavares:28322/default-channel-to-stable-on-tarball, r=brson
Use --release-channel=stable by default on releases

> Release tarballs should be compilable with just basic ./configure ;
> make ; sudo make install without having to pass special flags to
> configure. This is the case of the --release-channel option, that must
> be changed in the releases.

This commit detects the presence of .git, as it happens on other parts
of `configure` to assume it is a tarball. Then it changes the default
value stored, before parsing the arguments, while still allowing it to
be overriden before any action verifying the flag is done.

Closes #28322
2016-07-11 17:27:31 -07:00
Ben Boeckel
1bcd60682d llvm, rt: build using the Ninja generator if available
The Ninja generator generally builds much faster than make. It may also
be used on Windows to have a vast speed improvement over the Visual
Studio generators.

Currently hidden behind an `--enable-ninja` flag because it does not
obey the top-level `-j` or `-l` flags given to `make`.
2016-07-07 21:10:18 -04:00
bors
2b59647fae Auto merge of #34515 - alexcrichton:more-checks, r=brson
configure: Check for valid Python on MinGW as well

The LLVM build system is somewhat picky about which Python is used to build it
as it's known to be incompatible with the default `python2` package that ships
with MinGW. This was previously detected for MSVC builds but the logic was left
out for MinGW by accident (now that we've switched to cmake builds for LLVM
everywhere).

This corrects the `./configure` check and also updates the `README.md`
accordingly. Additionally, a number of instructions were updated to work with
the most recent copy of MSYS2.

Closes https://github.com/rust-lang/rust/issues/28260
Closes #34489
2016-07-02 00:29:06 -07:00
bors
85c31af981 Auto merge of #34541 - jseyfried:rollup, r=jseyfried
Rollup of 5 pull requests

 - Successful merges: #34105, #34305, #34512, ~~#34531,~~ #34547
2016-06-30 01:49:45 -07:00
Alex Crichton
213f1638d9 configure: Fix cross-compiling LLVM for realz
Actually got it working this time, and it was again just a problem specifying
the llvm-tblgen binary. We need to point it at the $CFG_BUILD target's tblgen
and then we also needed to correct the path a bit.
2016-06-29 09:05:18 -07:00
Alex Crichton
cb74a5874f configure: Check for valid Python on MinGW as well
The LLVM build system is somewhat picky about which Python is used to build it
as it's known to be incompatible with the default `python2` package that ships
with MinGW. This was previously detected for MSVC builds but the logic was left
out for MinGW by accident (now that we've switched to cmake builds for LLVM
everywhere).

This corrects the `./configure` check and also updates the `README.md`
accordingly. Additionally, a number of instructions were updated to work with
the most recent copy of MSYS2.

Closes #34489
2016-06-27 18:14:54 -07:00
CensoredUsername
37f0f67682 Support CMake installations in paths containing spaces 2016-06-27 23:39:51 +02:00
bors
8c63d12dc3 Auto merge of #34055 - brson:cmake, r=alexcrichton
Convert makefiles to build LLVM/compiler-rt with CMake

This is certainly buggy, but I have successfully built on x86_64-unknown-linux-gnu and x86_64-pc-windows-gnu. I haven't built successfully on mac yet, and I've seen mysterious test failures on Linux, but I'm interested in throwing this at the bots to see what they think.
2016-06-23 23:33:32 -07:00
Brian Anderson
59db95b499 Convert makefiles to build LLVM/compiler-rt with CMake 2016-06-21 19:54:28 -07:00
Alex Crichton
3c778953d5 configure: Remove clang version checks
We no C++ and an incredibly small amount of C code as part of the build, so
there's not really much need for us to strictly check the version of compilers
as we're not really stressing anything. LLVM is a pretty huge chunk of C++ but
it should be the responsibility of LLVM to ensure that it can build with a
particular clang/gcc version, not ours (as this logic changes over time).

These version checks seem to basically just by us a regular stream of PRs every
six weeks or so when a new version is releases, so they're not really buying us
much. As a result, remove them and we can add then back piecemeal perhaps as a
blacklist if we really need to.
2016-06-20 10:05:26 -07:00
marudor
7508de57b0 fix build for clang 8.0 2016-06-18 10:38:11 +02:00
petevine
683f08f745 Remove stray word 2016-06-13 01:05:32 +02:00
Bruno Tavares
970f8d8731 Use --release-channel=stable by default on releases
> Release tarballs should be compilable with just basic ./configure ;
> make ; sudo make install without having to pass special flags to
> configure. This is the case of the --release-channel option, that must
> be changed in the releases.

This commit detects the presence of .git, as it happens on other parts
of `configure` to assume it is a tarball. Then it changes the default
value stored, before parsing the arguments, while still allowing it to
be overriden before any action verifying the flag is done.

Closes #28322
2016-06-12 19:59:36 -03:00
Steve Klabnik
dd1198d025 Rollup merge of #34104 - nagisa:cfg-llvm-up, r=alexcrichton
Require LLVM 3.7

We are using getMCTargetInfo which is 3.7+. I’m not sure whether 3.7 works though.

Fixes https://github.com/rust-lang/rust/issues/34103

r? @alexcrichton
2016-06-07 10:43:57 -04:00
Simonas Kazlauskas
12abddb06b Require LLVM 3.7
We are using getMCTargetInfo which is 3.7+
2016-06-06 01:25:11 +03:00
Seo Sanghyeon
a7e96af377 Unsupport wget 2016-06-03 20:53:46 +09:00
Josh Stone
3406c55144 mk: Add --enable-local-rebuild to bootstrap from the current release
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.
2016-05-22 00:09:33 -07:00
Nerijus Arlauskas
b6fc4abe44 Add armv7-linux-androideabi target. 2016-05-07 13:29:57 +03:00
Brian Anderson
6bc9318318 configure: Add a sanity check for tarballs without submodules
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.
2016-04-29 19:39:22 +00:00
bors
ef57fb7144 Auto merge of #33084 - alexcrichton:osx-python-sanity, r=michaelwoerister
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
2016-04-23 01:18:03 -07:00
Guillaume Bonnet
46b75eb54b configure: Move --disable-option-checking to a more appropriate location 2016-04-22 18:24:31 +02:00
Guillaume Bonnet
b22c8ec5c7 configure: Support --disable-option-checking 2016-04-22 18:22:50 +02:00
Alex Crichton
cbe6292c58 mk: Force system python for LLDB tests on OSX
Force usage of /usr/bin/python whenever we run LLDB tests on OSX because it
looks like no other Python will work.
2016-04-19 09:57:00 -07:00
Manish Goregaokar
6e360e521f Rollup merge of #32731 - alexcrichton:known-bootstrap-key, r=brson
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.
2016-04-07 23:26:18 +05:30
Alex Crichton
c822546c9e 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.
2016-04-04 11:24:44 -07:00
Alex Crichton
a3fdde7453 mk: Add configure option for disabling codegen tests
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
2016-04-03 00:18:44 -07:00
Alex Crichton
7668b4bec2 mk: A few build fixes for i586-pc-windows-msvc
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.
2016-03-29 16:43:49 -07:00
Doug Goldstein
ed28247926 configure: update required LLVM version
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>
2016-03-24 13:11:08 -05:00
ituxbag
79da64a637 Added version 7.3* for Apple's clang compiler 2016-03-22 13:44:33 +01:00
Eduard Burtescu
835e2bdf7d Add -Z orbit for forcing MIR for everything, unless #[rustc_no_mir] is used. 2016-03-17 21:51:55 +02: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
bors
df128bdc4c Auto merge of #31620 - alexcrichton:fix-out-of-tree-builds, r=brson
This removes creating some extraneous directories and also fixes some submodule management with out of tree builds.

Closes #31619
2016-02-20 08:47:25 +00:00
Robin Kruppe
999051dbe3 configure: require Python 2.7
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.
2016-02-13 22:20:42 +01:00
Alex Crichton
680bdbc2a7 rustbuild: Don't make any directories when enabled
As part of the ./configure step don't create any directories if rustbuild is
enable as rustbuild will take care of everything.
2016-02-12 16:40:06 -08:00
Alex Crichton
bb2e92171f configure: Add an option to use the cargo build system
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!
2016-02-11 11:12:33 -08:00
Alex Crichton
7cbd2457ad configure: Remove default NDK path value
This likely isn't always valid, and subverts auto-detection.
2016-02-11 10:42:45 -08:00
Brian Anderson
d6c0d859f6 Add the asmjs-unknown-emscripten triple. Add cfgs to libs.
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.
2016-02-06 20:56:14 +00:00
Nikita Baksalyar
ebab24059a
Apply several fixes for Illumos support 2016-01-31 18:57:28 +03:00
Nikita Baksalyar
f189d7a693
Add Illumos support 2016-01-31 18:57:26 +03:00
bors
9041b93058 Auto merge of #31298 - japaric:mips-musl, r=alexcrichton
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
2016-01-31 12:27:06 +00:00
Brian Anderson
59b2a29e8e configure: Remove compatibility hacks for windows triples
Buildbot was updated long ago to use the correct triples.

The putvar here is emitting garbage into `configure --help` so
I want it gone.
2016-01-29 15:55:11 -08:00
Jorge Aparicio
7b026f0355 add support for mips(el)-unknown-linux-musl
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.
2016-01-29 18:46:25 -05:00
Michael Woerister
862911df9a Implement the translation item collector.
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.
2016-01-26 10:17:45 -05:00
mopp
c0984e42bd fix condition for clang 2016-01-24 19:36:02 +09:00
Guillaume Bonnet
6aa86e5cd1 configure: Do not generate two stage0 rustlib dirs when --libdir is set 2016-01-21 13:18:47 +01:00
bors
0b77e50b41 Auto merge of #30985 - alexcrichton:downgrade-jemaloc, r=brson
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)
2016-01-20 20:14:18 +00:00
Alex Crichton
884de56f71 Downgrade bundled jemalloc version
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)
2016-01-20 09:38:16 -08:00
Martin
da56967a3e Enumerate acceptable clang versions 2016-01-18 15:57:57 +01:00
Martin
2f1703d161 Allow clang 7.x in configuration
I'm using clang 7.2 which works just fine to compile Rust with, but was disallowed.
2016-01-18 04:44:35 +01:00
Anton Blanchard
b372910476 Add powerpc64 and powerpc64le support
This adds support for big endian and little endian PowerPC64.
make check runs clean apart from one big endian backtrace issue.
2016-01-13 01:39:00 +00:00