Commit graph

674 commits

Author SHA1 Message Date
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
Brian Anderson
ce81f24340 configure: Add --extra-filename flag
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
2015-12-29 00:18:15 +00:00
Steve Klabnik
8759f1f4cf Rollup merge of #30251 - nodakai:patch-1, r=pnkfelix
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.
2015-12-23 18:09:11 -05:00
bors
45e52dadb8 Auto merge of #30353 - alexcrichton:rpath-by-default, r=brson
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
2015-12-23 00:42:19 +00:00
Kai Noda
00e6667b98 configure: test $SHELL's permission
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.
2015-12-22 16:25:47 +08:00
Richard Diamond
0442be8e1c Add PNaCl target info to the makefile target cfgs and initialize the PNaCl target
machine if available.
2015-12-19 00:26:53 -06: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
Alex Crichton
9bff8b090a configure: Enable -C rpath by default
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
2015-12-12 09:01:52 -08:00
bors
69b2fce7bb Auto merge of #29858 - fhahn:abort-if-path-has-spaces, r=brson
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.
2015-12-01 21:38:20 +00:00
Angus Lees
07b7f2fbc9 Set CFLAGS/LDFLAGS/etc according to Debian policy
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.
2015-11-20 12:51:10 -02:00
Florian Hahn
9612c9ab20 Abort configure if source path contains spaces, closes #18477 2015-11-16 23:57:21 +01:00
bors
cc403b6c33 Auto merge of #29478 - angelsl:msvc2, r=alexcrichton
r? @alexcrichton
2015-11-04 06:07:24 +00:00
angelsl
9fe4e962e1 Build compiler-rt/builtins with MSVC 2015-11-04 11:43:41 +08:00
Vadim Chugunov
4e0c6db67f Windows: Move target libraries to $rustroot/lib/rustlib/... - for symmetry with all other platforms. 2015-10-31 23:29:39 -07:00
Alex Crichton
f351b69edd Revert "Build compiler-rt/builtins with MSVC"
This reverts commit b09e8f51a2.
2015-10-30 10:36:38 -07:00
angelsl
b09e8f51a2 Build compiler-rt/builtins with MSVC 2015-10-28 15:23:20 +08:00
bors
6843ea4a46 Auto merge of #28717 - nagisa:optional-no-landing-pads, r=alexcrichton
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.
2015-10-05 21:47:47 +00:00
Robin Kruppe
4df35ba454 Stop probing for pandoc and xelatex, they are not used any more. 2015-10-01 14:34:31 +02:00
Simonas Kazlauskas
cefadf05f9 Enable and make stage0 landing pads optional 2015-09-29 20:18:03 +03:00
Sebastian Wicki
c099cfab06 Add support for the rumprun unikernel
For most parts, rumprun currently looks like NetBSD, as they share the same
libc and drivers. However, being a unikernel, rumprun does not support
process management, signals or virtual memory, so related functions
might fail at runtime. Stack guards are disabled exactly for this reason.

Code for rumprun is always cross-compiled, it uses always static
linking and needs a custom linker.
2015-09-26 14:10:14 +02:00
Sébastien Marie
913fe6dbe9 add support for non-standard name of stdc++ library
it makes rustc compatible with gcc installation that are using
`--program-transform-name' configure flag (on OpenBSD for example).

- detects at configure the name of stdc++ library on the system

- use the detected name in llvm makefile (with enable-static-stdcpp),
  and pass it to mklldeps.py

- generate mklldeps.rs using this detected name

note that CFG_STDCPP_NAME is about stdc++ name, not about libc++. If
using libc++, the default name will be `stdc++', but it won't be used
when linking.
2015-09-18 18:03:59 +02:00
bors
d89a10b0a6 Auto merge of #28340 - brson:configure, r=alexcrichton
Redirect stdout on the python bogosity detector. This is printing
pwd to the terminal currently.

Reformat the bogus python/cmake messages so they format correctly.
echo does not always escape newlines (it doesn't here), and multiline
strings don't whitespace munch.

r? @alexcrichton
2015-09-12 02:57:01 +00:00
Brian Anderson
2662a72537 configure cleanup on windows
Redirect stdout on the python bogosity detector. This is printing
pwd to the terminal currently.

Reformat the bogus python/cmake messages so they format correctly.
echo does not always escape newlines (it doesn't here), and multiline
strings don't whitespace munch.
2015-09-11 14:33:29 -07:00
bors
5c56887903 Auto merge of #28331 - semarie:openbsd-configure-egcc, r=alexcrichton
under OpenBSD, it could be have present multiples versions of gcc compiler:
  - gcc-4.2 (with patchs) : c/c++ compiler present in `/usr/bin`. It is unusable to build recent LLVM (so rustc too).
  - gcc/g++ -4.9 : c/c++ compiler, installed as third-party with "ports" mechanism. The compiler is installed in `/usr/local` as `egcc` (and `eg++`).

this PR adds probing for `egcc` for `CFG_GCC`, if the first probed `gcc` is too old. It will set `CC` and `CXX` too, in order to pass the variables to LLVM configure if builded.

please note this PR is a first step in order to build rustc under OpenBSD with unpatched tree.

r? @alexcrichton

cc @brson @dhuseby
2015-09-10 23:33:31 +00:00
Sébastien Marie
9ac36f4665 disable jemalloc on OpenBSD
depending of the compiler used, jemalloc configure don't detect
correctly some parameters.
2015-09-10 18:52:19 +02:00
Sébastien Marie
90043cbbf0 openbsd: probe CFG_GCC egcc
if default CFG_GCC is too old, probe also egcc (which is gcc from
ports).

set CC/CXX too, in order to pass them to LLVM
2015-09-10 11:59:01 +02:00
Dong Zhou
0ad631cf7c Fix clang too 2015-09-09 11:45:59 -04:00
Dong Zhou
d77a249917 Fix configure for LLVM 3.8 2015-09-09 11:32:05 -04:00
Diggory Blake
f86c853fee Fix escaping in msvc builds 2015-09-04 10:03:56 +01:00
Tim JIANG
a1b2deb33b New cross target: i686-linux-android
- All the libstd tests are now passing in the optimized build against
  a Zenfone2 and the x86 Android simulator.
2015-08-23 15:38:11 +08: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
Sylvestre Ledru
5bcbc5c735 Bug #27621 - Make sure that LLVM FileCheck is available on the system 2015-08-10 09:53:00 +02:00
Dave Huseby
40eb53c409 recent changes to search for gcc/clang on freebsd and this fixes #14381 2015-07-28 21:23:19 -07:00
bors
aa6efd959e Auto merge of #27173 - mark-buer:split-android-ndks, r=alexcrichton
Allows a multi-Android-target Rust compiler to be built.
Without these (or similar) changes, only a single-Android-target Rust compiler is possible.
Please see https://internals.rust-lang.org/t/dual-target-android-rust-compiler/2382/3 for additional context.
2015-07-28 17:58:18 +00:00
Mark Buer
33a7e67904 Splits Android NDK path configuration. 2015-07-28 19:21:04 +12:00
bors
8b835572b9 Auto merge of #27250 - alexcrichton:ucrt, r=brson
Visual Studio 2015, recently released, includes the Universal CRT, a different
flavor than was provided before. The binaries and header files for this library
are included in new locations not previously known about by gcc-rs, and this
commit adds support for the necessary probing to find these.

Unfortunately there are no prior examples of this probing to be found in
frameworks like CMake or clang, so this is done is a bit of a sketchy method
today. It assumes that the installation is in a relatively standard format and
then blindly looks for the location of the UCRT. I'd love to switch this over to
using registry keys for probing, but I was currently unable to find such keys.

This should enable the compiler to work outside VS 2015 dev tools prompts.
2015-07-27 23:38:04 +00:00
Steven Stewart-Gallus
f3bfbda665 Standardize on non-zero checks for configure 2015-07-26 14:18:30 -07:00
Alex Crichton
95ec4be02b configure: Add support for VS 2015
Adds support to the configure script for detecting Visual Studio 2015 being
installed and builds LLVM/uses cl with that compiler. The compiler will
automatically use this MSVC linker anyway because it's the highest version.
2015-07-23 19:38:00 -07:00
Felix S. Klock II
ac33f1572b fix configure: allow both --enable-debug and --disable-debuginfo
in one invocation.
2015-07-20 10:07:53 +02:00
Manish Goregaokar
2c49927ae4 Rollup merge of #27028 - Gankro:travis, r=alexcrichton
This has travis build LLVM and rustc up to stage1, but not run any tests. It seems wasteful to have the ultimate might of travis running on every PR just to check for whitespace errors. This is a pure subset of the bootstrap, so it shouldn't ever spuriously break.

`make tidy` still runs first, so we still get \"fast errors\" on bad style. However once make tidy passes, the build will simply keep running to try to make rustc. `tidy` takes ~3 mins to complete, so if your build runs longer you can be confident we've gone on to build LLVM/rustc. In principle this is configured to use ccache (it shows up in the build logs as uploaded/downloaded), but I found no actual performance changes in using it.

Maybe someone at @travis-ci knows what's up with that.

For reference, here is a successful build with ccache enabled: https://travis-ci.org/Gankro/rust/builds/70821237

and one without: https://travis-ci.org/Gankro/rust/builds/70812814

Builds seem to take about 41mins regardless.

r? @alexcrichton
2015-07-16 10:49:23 +05:30
Alexis Beingessner
e8a03285b7 Ratchet up travis to build stage1 and our own LLVM.
Tidy is still run first for failing fast on the easy stuff.

To accomplish this we have travis actually persist ccache across builds. This
has LLVM built within 6 minutes, and all of stage1 built within 18.
Caching should work on fresh PRs (cache acquired from the master branch).
Because all we persist is ccache, there is minimal danger of persisting corrupt
build state.

I had to mangle `configure` a bit to make --enable-ccache work when custom
compilers are provide via CC and CXX.
2015-07-15 10:48:50 -07:00
Ryan Pendleton
7131e6f378 verify Apple LLVM versions independently, since the "based on LLVM" version is no longer reported 2015-07-13 00:33:36 -06:00
Alex Newman
0b7c4f57f6 Add netbsd amd64 support 2015-07-01 19:09:14 -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
Dave Huseby
44d487d37c stupid missing dollar sign 2015-06-24 12:48:08 -07:00
Dave Huseby
97fb1c241c adding fallback to clang if gcc not available 2015-06-24 12:39:58 -07:00
Dave Huseby
4de71c7ef6 allowing fallback to clang on freebsd when needed 2015-06-24 12:39:58 -07:00
Sébastien Marie
e0283ab9c4 support llvm version 3.7 in configure
LLVM version 3.7 should be supported as external version (when using
--llvm-root configure option), as the current embedded LLVM version is
3.7.0svn.
2015-06-24 08:36:42 +02:00
OGINO Masanori
59399088ca Put CFG_BUILD triples into CFG_HOST triples.
I've configured with the parameters suggested by @brson in #18670 and
confirmed that it works on Gentoo Linux amd64.

Fixes #18670.

Signed-off-by: OGINO Masanori <masanori.ogino@gmail.com>
2015-06-22 12:53:34 +09:00
Ulrik Sverdrup
70269cd8ef mk: Build crates with relative paths to rustc
The path we pass to rustc will be visible in panic messages and
backtraces: they will be user visible!

Avoid junk in these paths by passing relative paths to rustc.

For most advanced users, `libcore` or `libstd` in the path will be
a clue to the location -- inside our code, not theirs.

Store both the relative path to the source as well as the absolute.
Use the relative path where it matters, compiling the main crates,
instead of changing all of the build process to cope with relative
paths.

Example output after this patch:

```
$ ./testunwrap
thread '<main>' panicked at 'called `Option::unwrap()` on a `None` value', ../src/libcore/option.rs:362
$ RUST_BACKTRACE=1 ./testunwrap
thread '<main>' panicked at 'called `Option::unwrap()` on a `None` value', ../src/libcore/option.rs:362
stack backtrace:
   1:     0x7ff59c1e9956 - sys::backtrace::write::h67a542fd2b201576des
                        at ../src/libstd/sys/unix/backtrace.rs:158
   2:     0x7ff59c1ed5b6 - panicking::on_panic::h3d21c41cdd5c12d41Xw
                        at ../src/libstd/panicking.rs:58
   3:     0x7ff59c1e7b6e - rt::unwind::begin_unwind_inner::h9f3a5440cebb8baeLDw
                        at ../src/libstd/rt/unwind/mod.rs:273
   4:     0x7ff59c1e7f84 - rt::unwind::begin_unwind_fmt::h4fe8a903e0c296b0RCw
                        at ../src/libstd/rt/unwind/mod.rs:212
   5:     0x7ff59c1eced7 - rust_begin_unwind
   6:     0x7ff59c22c11a - panicking::panic_fmt::h00b0cd49c98a9220i5B
                        at ../src/libcore/panicking.rs:64
   7:     0x7ff59c22b9e0 - panicking::panic::hf549420c0ee03339P3B
                        at ../src/libcore/panicking.rs:45
   8:     0x7ff59c1e621d - option::Option<T>::unwrap::h501963526474862829
   9:     0x7ff59c1e61b1 - main::hb5c91ce92347d1e6eaa
  10:     0x7ff59c1f1c18 - rust_try_inner
  11:     0x7ff59c1f1c05 - rust_try
  12:     0x7ff59c1ef374 - rt::lang_start::h7e51e19c6677cffe5Sw
                        at ../src/libstd/rt/unwind/mod.rs:147
                        at ../src/libstd/rt/unwind/mod.rs:130
                        at ../src/libstd/rt/mod.rs:128
  13:     0x7ff59c1e628e - main
  14:     0x7ff59b3f6b44 - __libc_start_main
  15:     0x7ff59c1e6078 - <unknown>
  16:                0x0 - <unknown>
```
2015-06-13 01:41:52 +02:00
Alex Crichton
3d74fbd496 configure: Fix LLVM output dir on MSVC
If LLVM assertions are enabled for MSVC, it looks like the output directory is
still just `Release` (or assertions are just always ignored on MSVC).
2015-06-03 22:08:47 -07:00
bors
5b56d73dc0 Auto merge of #25984 - Manishearth:rollup, r=Manishearth
- Successful merges: #25939, #25963, #25970, #25971, #25974
- Failed merges:
2015-06-03 09:44:26 +00:00
Manish Goregaokar
27dd5e9ce9 Rollup merge of #25971 - richo:configurable-python, r=alexcrichton
r? @alexcrichton
2015-06-03 14:46:41 +05:30
Manish Goregaokar
3fd41d61ab Rollup merge of #25939 - wca:fix-freebsd-configure, r=alexcrichton
Bug fixes for configure on FreeBSD:
- Don't ban using gcc; newer versions can be installed and other checks should enforce its suitability.
- Don't force Rust to link itself with /usr/local/lib{,gcc4[46]}, which causes builds to fail if Rust is already installed.  I've not been able to find an use case where this is actually necessary.
2015-06-03 14:46:40 +05:30
bors
a5979be9fe Auto merge of #25938 - wca:fix-clang-check-compatibility, r=alexcrichton
Not all /bin/sh have [[ available, so for compatibility using case..esac
for pattern matching is better.
2015-06-03 06:07:44 +00:00
Richo Healey
de4a1dca2b configure: Allow specifying your python with --python 2015-06-02 15:16:30 -07:00
bors
a49ae5bd43 Auto merge of #25858 - alexcrichton:disable-os-tls, r=brson
This commit adds a ./configure option called `--disable-elf-tls` which disables
ELF based TLS (that which is communicated to LLVM) on platforms which already
support it. OSX 10.6 does not support this form of TLS, and some users of Rust
need to target 10.6 and are unable to do so due to the usage of TLS. The
standard library will continue to use ELF based TLS on OSX by default (as the
officially supported platform is 10.7+), but this adds an option to compile the
standard library in a way that is compatible with 10.6.

Closes #25342
2015-06-01 19:51:57 +00:00
Andrew Foote
d4389c52ab remove duplicate "don't" 2015-05-30 18:13:51 -07:00
Alex Crichton
1b5f9cb1f1 std: Add an option to disable ELF based TLS
This commit adds a ./configure option called `--disable-elf-tls` which disables
ELF based TLS (that which is communicated to LLVM) on platforms which already
support it. OSX 10.6 does not support this form of TLS, and some users of Rust
need to target 10.6 and are unable to do so due to the usage of TLS. The
standard library will continue to use ELF based TLS on OSX by default (as the
officially supported platform is 10.7+), but this adds an option to compile the
standard library in a way that is compatible with 10.6.
2015-05-28 10:14:42 -07:00
Kubilay Kocak
d323c14f63 Remove redundant compiler check. Allow CC override
Currently, there are two conditional blocks that exist to check for "clang or gcc"

On line 866:

```
if [ -z "$CFG_ENABLE_CLANG" -a -z "$CFG_GCC" ]
then
    err "either clang or gcc is required"
fi
```
and on line 1019:

```
if [ -z "$CC" -a -z "$CFG_ENABLE_CLANG" -a -z "$CFG_GCC" ]
then
    err "either clang or gcc is required"
fi
```

Given the order of the clauses, this results in the "either clang or gcc is required" error from the earlier block, (even) when CC is set. 

The expected behaviour is to honour user-flags, in this case CC.

Aside from removing all hand-holdy compiler checks in favour of actual compiler *feature* checks, this change removes the redundant former block in favour of the latter block, which appears designed to allow the expected behaviour.
2015-05-26 18:23:33 +10:00
Will Andrews
bc85eb49f5 Use case..esac instead of [[.
Not all /bin/sh have [[ available, so for compatibility using case..esac
for pattern matching is better.
2015-05-23 14:11:50 -06:00
Will Andrews
31764a98ff Don't force FreeBSD to use clang.
Newer gcc can be installed, so it should be used if possible.  Checks
elsewhere in configure should enforce this.
2015-05-23 14:09:11 -06:00
Oliver Schneider
a650075f89 Rollup merge of #25722 - nickdesaulniers:configureClang37, r=brson
Was able to successfully configure.  Building and testing now.
2015-05-23 19:03:20 +02:00
Nick Desaulniers
64f8640164 allow clang 3.7 to be used when configuring Fixes #25720 2015-05-22 16:07:25 -07:00
Geoffrey Thomas
dfacdcf25d configure: Fix printing of commands from run
The `run` function passed its argument to `msg` via `"$@"`, but `msg`
only printed its first argument. I think the intention was for `msg` to
print all its arguments. (If not, `run` should only `msg "$1"`.)
2015-05-22 00:39:24 -04:00
Geoffrey Thomas
1e180b809f configure: Clarify error message about missing dependencies
Took me a moment to figure out that the appropriate response to
"need program file" was to install the program named "file", not
to think "If I didn't need the program file, why would I be
compiling things?".
2015-05-22 00:38:49 -04:00
Sébastien Marie
0cac79181b use posix command to extract first 8 chars
the "-c" option of head isn't a posix option, and it isn't supported
under openbsd.

prefer the use of cut -c 1-8 (which is posix) to extract the first 8
chars.
2015-05-20 13:54:14 +02:00
bors
43cf733bfa Auto merge of #25350 - alexcrichton:msvc, r=brson
Special thanks to @retep998 for the [excellent writeup](https://github.com/rust-lang/rfcs/issues/1061) of tasks to be done and @ricky26 for initially blazing the trail here!

# MSVC Support

This goal of this series of commits is to add MSVC support to the Rust compiler
and build system, allowing it more easily interoperate with Visual Studio
installations and native libraries compiled outside of MinGW.

The tl;dr; of this change is that there is a new target of the compiler,
`x86_64-pc-windows-msvc`, which will not interact with the MinGW toolchain at
all and will instead use `link.exe` to assemble output artifacts.

## Why try to use MSVC?

With today's Rust distribution, when you install a compiler on Windows you also
install `gcc.exe` and a number of supporting libraries by default (this can be
opted out of). This allows installations to remain independent of MinGW
installations, but it still generally requires native code to be linked with
MinGW instead of MSVC. Some more background can also be found in #1768 about the
incompatibilities between MinGW and MSVC.

Overall the current installation strategy is quite nice so long as you don't
interact with native code, but once you do the usage of a MinGW-based `gcc.exe`
starts to get quite painful.

Relying on a nonstandard Windows toolchain has also been a long-standing "code
smell" of Rust and has been slated for remedy for quite some time now. Using a
standard toolchain is a great motivational factor for improving the
interoperability of Rust code with the native system.

## What does it mean to use MSVC?

"Using MSVC" can be a bit of a nebulous concept, but this PR defines it as:

* The build system for Rust will build as much code as possible with the MSVC
  compiler, `cl.exe`.
* The build system will use native MSVC tools for managing archives.
* The compiler will link all output with `link.exe` instead of `gcc.exe`.

None of these are currently implemented today, but all are required for the
compiler to fluently interoperate with MSVC.

## How does this all work?

At the highest level, this PR adds a new target triple to the Rust compiler:

    x86_64-pc-windows-msvc

All logic for using MSVC or not is scoped within this triple and code can
conditionally build for MSVC or MinGW via:

    #[cfg(target_env = "msvc")]

It is expected that auto builders will be set up for MSVC-based compiles in
addition to the existing MinGW-based compiles, and we will likely soon start
shipping MSVC nightlies where `x86_64-pc-windows-msvc` is the host target triple
of the compiler.

# Summary of changes

Here I'll explain at a high level what many of the changes made were targeted
at, but many more details can be found in the commits themselves. Many thanks to
@retep998 for the excellent writeup in rust-lang/rfcs#1061 and @rick26 for a lot
of the initial proof-of-concept work!

## Build system changes

As is probably expected, a large chunk of this PR is changes to Rust's build
system to build with MSVC. At a high level **it is an explicit non goal** to
enable building outside of a MinGW shell, instead all Makefile infrastructure we
have today is retrofitted with support to use MSVC instead of the standard MSVC
toolchain. Some of the high-level changes are:

* The configure script now detects when MSVC is being targeted and adds a number
  of additional requirements about the build environment:
  * The `--msvc-root` option must be specified or `cl.exe` must be in PATH to
    discover where MSVC is installed. The compiler in use is also required to
    target x86_64.
  * Once the MSVC root is known, the INCLUDE/LIB environment variables are
    scraped so they can be reexported by the build system.
  * CMake is required to build LLVM with MSVC (and LLVM is also configured with
    CMake instead of the normal configure script).
  * jemalloc is currently unconditionally disabled for MSVC targets as jemalloc
    isn't a hard requirement and I don't know how to build it with MSVC.
* Invocations of a C and/or C++ compiler are now abstracted behind macros to
  appropriately call the underlying compiler with the correct format of
  arguments, for example there is now a macro for "assemble an archive from
  objects" instead of hard-coded invocations of `$(AR) crus liboutput.a ...`
* The output filenames for standard libraries such as morestack/compiler-rt are
  now "more correct" on windows as they are shipped as `foo.lib` instead of
  `libfoo.a`.
* Rust targets can now depend on native tools provided by LLVM, and as you'll
  see in the commits the entire MSVC target depends on `llvm-ar.exe`.
* Support for custom arbitrary makefile dependencies of Rust targets has been
  added. The MSVC target for `rustc_llvm` currently requires a custom `.DEF`
  file to be passed to the linker to get further linkages to complete.

## Compiler changes

The modifications made to the compiler have so far largely been minor tweaks
here and there, mostly just adding a layer of abstraction over whether MSVC or a
GNU-like linker is being used. At a high-level these changes are:

* The section name for metadata storage in dynamic libraries is called `.rustc`
  for MSVC-based platorms as section names cannot contain more than 8
  characters.
* The implementation of `rustc_back::Archive` was refactored, but the
  functionality has remained the same.
* Targets can now specify the default `ar` utility to use, and for MSVC this
  defaults to `llvm-ar.exe`
* The building of the linker command in `rustc_trans:🔙:link` has been
  abstracted behind a trait for the same code path to be used between GNU and
  MSVC linkers.

## Standard library changes

Only a few small changes were required to the stadnard library itself, and only
for minor differences between the C runtime of msvcrt.dll and MinGW's libc.a

* Some function names for floating point functions have leading underscores, and
  some are not present at all.
* Linkage to the `advapi32` library for crypto-related functions is now
  explicit.
* Some small bits of C code here and there were fixed for compatibility with
  MSVC's cl.exe compiler.

# Future Work

This commit is not yet a 100% complete port to using MSVC as there are still
some key components missing as well as some unimplemented optimizations. This PR
is already getting large enough that I wanted to draw the line here, but here's
a list of what is not implemented in this PR, on purpose:

## Unwinding

The revision of our LLVM submodule [does not seem to implement][llvm] does not
support lowering SEH exception handling on the Windows MSVC targets, so
unwinding support is not currently implemented for the standard library (it's
lowered to an abort).

[llvm]: https://github.com/rust-lang/llvm/blob/rust-llvm-2015-02-19/lib/CodeGen/Passes.cpp#L454-L461

It looks like, however, that upstream LLVM has quite a bit more support for SEH
unwinding and landing pads than the current revision we have, so adding support
will likely just involve updating LLVM and then adding some shims of our own
here and there.

## dllimport and dllexport

An interesting part of Windows which MSVC forces our hand on (and apparently
MinGW didn't) is the usage of `dllimport` and `dllexport` attributes in LLVM IR
as well as native dependencies (in C these correspond to
`__declspec(dllimport)`).

Whenever a dynamic library is built by MSVC it must have its public interface
specified by functions tagged with `dllexport` or otherwise they're not
available to be linked against. This poses a few problems for the compiler, some
of which are somewhat fundamental, but this commit alters the compiler to attach
the `dllexport` attribute to all LLVM functions that are reachable (e.g. they're
already tagged with external linkage). This is suboptimal for a few reasons:

* If an object file will never be included in a dynamic library, there's no need
  to attach the dllexport attribute. Most object files in Rust are not destined
  to become part of a dll as binaries are statically linked by default.
* If the compiler is emitting both an rlib and a dylib, the same source object
  file is currently used but with MSVC this may be less feasible. The compiler
  may be able to get around this, but it may involve some invasive changes to
  deal with this.

The flipside of this situation is that whenever you link to a dll and you import
a function from it, the import should be tagged with `dllimport`. At this time,
however, the compiler does not emit `dllimport` for any declarations other than
constants (where it is required), which is again suboptimal for even more
reasons!

* Calling a function imported from another dll without using `dllimport` causes
  the linker/compiler to have extra overhead (one `jmp` instruction on x86) when
  calling the function.
* The same object file may be used in different circumstances, so a function may
  be imported from a dll if the object is linked into a dll, but it may be
  just linked against if linked into an rlib.
* The compiler has no knowledge about whether native functions should be tagged
  dllimport or not.

For now the compiler takes the perf hit (I do not have any numbers to this
effect) by marking very little as `dllimport` and praying the linker will take
care of everything. Fixing this problem will likely require adding a few
attributes to Rust itself (feature gated at the start) and then strongly
recommending static linkage on Windows! This may also involve shipping a
statically linked compiler on Windows instead of a dynamically linked compiler,
but these sorts of changes are pretty invasive and aren't part of this PR.

## CI integration

Thankfully we don't need to set up a new snapshot bot for the changes made here as our snapshots are freestanding already, we should be able to use the same snapshot to bootstrap both MinGW and MSVC compilers (once a new snapshot is made from these changes).

I plan on setting up a new suite of auto bots which are testing MSVC configurations for now as well, for now they'll just be bootstrapping and not running tests, but once unwinding is implemented they'll start running all tests as well and we'll eventually start gating on them as well.

---

I'd love as many eyes on this as we've got as this was one of my first interactions with MSVC and Visual Studio, so there may be glaring holes that I'm missing here and there!

cc @retep998, @ricky26, @vadimcn, @klutzy 

r? @brson
2015-05-20 00:31:55 +00:00
Alex Crichton
b56d47cc80 mk: Enable building LLVM targeting MSVC
This commit modifies the makefiles to enable building LLVM with cmake and Visual
Studio to generate an LLVM that targets MSVC. Rust's configure script requires
cmake to be installed when targeting MSVC and will configure LLVM with cmake
instead of the normal `./configure` script LLVM provides. The build will then
run cmake to execute the build instead of the normal `make`.

Currently `make clean-llvm` isn't supported on MSVC as I can't figure out how to
run a "clean" target for the Visual Studio files.
2015-05-19 10:52:57 -07:00
Alex Crichton
7cf0b1798b configure: Start adding MSVC support
This commit starts to add MSVC support to the ./configure script to enable the
build system to detect and build an MSVC target with the cl.exe compiler and
toolchain. The primary change here is a large sanity check when an MSVC target
is requested (and currently only `x86_64-pc-windows-msvc` is recognized).

When building an MSVC target, the configure script either requires the
`--msvc-root` argument or for `cl.exe` to be in `PATH`. It also requires that if
in the path `cl.exe` is the 64-bit version of the compiler.

Once detected the configure script will run the `vcvarsall.bat` script provided
by Visual Studio to learn about the `INCLUDE` and `LIB` variables needed by the
`cl.exe` compiler to run (the default include/lib paths for the
compiler/linker). These variables are then reexported when running `make` to
ensure that our own compiles are running the same toolchain.

The purpose of this detection and environment variable scraping is to avoid
requiring the build itself to be run inside of a `cmd.exe` shell but rather
allow it to run in the currently expected MinGW/MSYS shell.
2015-05-19 10:52:55 -07:00
bors
e5394240a2 Auto merge of #25208 - lfairy:version-hash, r=brson
The code takes a prefix of the MD5 hash of the version string.

Since the hash command differs across GNU and BSD platforms, we scan for
the right one in the configure script.

Closes #25007
2015-05-14 00:42:32 +00:00
Ricky Taylor
315750ac92 Very hacky MSVC hacks.
Conflicts:
	mk/platform.mk
	src/librustc/session/config.rs
	src/librustc_back/target/aarch64_apple_ios.rs
	src/librustc_back/target/aarch64_linux_android.rs
	src/librustc_back/target/arm_linux_androideabi.rs
	src/librustc_back/target/arm_unknown_linux_gnueabi.rs
	src/librustc_back/target/arm_unknown_linux_gnueabihf.rs
	src/librustc_back/target/armv7_apple_ios.rs
	src/librustc_back/target/armv7s_apple_ios.rs
	src/librustc_back/target/i386_apple_ios.rs
	src/librustc_back/target/i686_apple_darwin.rs
	src/librustc_back/target/i686_pc_windows_gnu.rs
	src/librustc_back/target/i686_unknown_dragonfly.rs
	src/librustc_back/target/i686_unknown_linux_gnu.rs
	src/librustc_back/target/mips_unknown_linux_gnu.rs
	src/librustc_back/target/mipsel_unknown_linux_gnu.rs
	src/librustc_back/target/mod.rs
	src/librustc_back/target/powerpc_unknown_linux_gnu.rs
	src/librustc_back/target/x86_64_apple_darwin.rs
	src/librustc_back/target/x86_64_apple_ios.rs
	src/librustc_back/target/x86_64_pc_windows_gnu.rs
	src/librustc_back/target/x86_64_unknown_dragonfly.rs
	src/librustc_back/target/x86_64_unknown_freebsd.rs
	src/librustc_back/target/x86_64_unknown_linux_gnu.rs
	src/librustc_back/target/x86_64_unknown_openbsd.rs
	src/librustc_llvm/lib.rs
	src/librustc_trans/back/link.rs
	src/librustc_trans/trans/base.rs
	src/libstd/os.rs
	src/rustllvm/RustWrapper.cpp
2015-05-12 14:50:36 -07:00
bors
8c9dc18355 Auto merge of #24859 - richo:valgrind-tests, r=brson
This stung me more than once in dev.

Bonus DRY'ing up of configure that I did on my way past.
2015-05-09 02:07:18 +00:00
Chris Wong
939c53ea42 configure: display correct version for md5sum
The old code simply scanned for the first digit, then munched anything
after that. This didn't work for md5sum, as it would see the "5" and
treat "5sum" as the version instead.

This patch tweaks the algorithm so that it looks for a second
consecutive digit (or dot) after the first. Since "md5sum" has only one
digit, the new code skips over it as intended.
2015-05-08 22:52:02 +12:00
Chris Wong
535040aab8 Generate CFG_FILENAME_EXTRA from the version
The code takes a prefix of the MD5 hash of the version string.

Since the hash command differs across GNU and BSD platforms, we scan for
the right one in the configure script.

Closes #25007
2015-05-08 22:26:26 +12:00
Carol Nichols
468cb052b8 Expand OS X versions referenced in configure message
10.10 is out, so it's weird to see a message that says you're on 10.9.
Change the message to be >=10.9.
2015-05-07 19:35:58 -04:00
bors
2f613bfaeb Auto merge of #24902 - bombless:configure, r=pnkfelix
Closes #24840
2015-04-30 15:16:24 +00:00
York Xiang
98b7aaf3ef Mention --enable-optimize for --enable-debug 2015-04-30 21:39:52 +08:00
Felix S. Klock II
bd4b984537 add --enable-debuginfo-tests, analogous to --disable-optimize-tests.
Then, decouple the question of whether the compiler/stdlib carry
debuginfo (which is controlled via `--enable-debuginfo` and implied by
`--enable-debug`) from the question of whether the tests carry
debuginfo (which now no longer is implied by `--enable-debug` nor
`--enable-debuginfo`, and is off by default).
2015-04-29 17:18:44 +02:00
bors
cadc67e8fd Auto merge of #24777 - alexcrichton:musl, r=brson
These commits build on [some great work on reddit](http://www.reddit.com/r/rust/comments/33boew/weekend_experiment_link_rust_programs_against/) for adding MUSL support to the compiler. This goal of this PR is to enable a `--target x86_64-unknown-linux-musl` argument to the compiler to work A-OK. The outcome here is that there are 0 compile-time dependencies for a MUSL-targeting build *except for a linker*. Currently this also assumes that MUSL is being used for statically linked binaries so there is no support for dynamically linked binaries with MUSL.

MUSL support largely just entailed munging around with the linker and where libs are located, and the major highlights are:

* The entirety of `libc.a` is included in `liblibc.rlib` (statically included as an archive).
* The entirety of `libunwind.a` is included in `libstd.rlib` (like with liblibc).
* The target specification for MUSL passes a number of ... flavorful options! Each option is documented in the relevant commit.
* The entire test suite currently passes with MUSL as a target, except for:
  * Dynamic linking tests are all ignored as it's not supported with MUSL
  * Stack overflow detection is not working MUSL yet (I'm not sure why)
* There is a language change included in this PR to add a `target_env` `#[cfg]` directive. This is used to conditionally build code for only MUSL (or for linux distros not MUSL). I highly suspect that this will also be used by Windows to target MSVC instead of a MinGW-based toolchain.

To build a compiler targeting MUSL you need to follow these steps:

1. Clone the current MUSL repo from `git://git.musl-libc.org/musl`. Build this as usual and install it.
2. Clone and build LLVM's [libcxxabi](http://libcxxabi.llvm.org/) library. Only the `libunwind.a` artifact is needed. I have tried using upstream libunwind's source repo but I have not gotten unwinding to work with it unfortunately. Move `libunwind.a` adjacent to MUSL's `libc.a`
3. Configure a Rust checkout with `--target=x86_64-unknown-linux-musl --musl-root=$MUSL_ROOT` where `MUSL_ROOT` is where you installed MUSL in step 1.

I hope to improve building a copy of libunwind as it's still a little sketchy and difficult to do today, but other than that everything should "just work"! This PR is not intended to include 100% comprehensive support for MUSL, as future modifications will probably be necessary.
2015-04-28 20:12:59 +00:00
Richo Healey
fc7faafae7 configure: Fail iff valgrind is explicitly requested but not available 2015-04-27 23:54:30 -07:00
bors
da2276e293 Auto merge of #24835 - rprichard:rfail-full, r=alexcrichton
This commit gets `make check-stage1` working again after #24718.

cc @tamird

r? @alexcrichton
2015-04-28 05:37:48 +00: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
Richo Healey
b982a751f4 configure: Disable valgrind-rpass if there's no valgrind 2015-04-27 01:04:22 -07:00
Richo Healey
a8ea78bc35 configure: generic run command 2015-04-27 00:58:31 -07:00
bors
314b1f16b7 Auto merge of #24679 - tamird:enable-debug, r=pnkfelix
r? @alexcrichton
2015-04-26 15:04:33 +00:00
Ryan Prichard
5e37729036 Add a new test group, rfail-full that runs rfail tests with fulldeps.
In most places in mk/tests.mk, it's positioned after rpass-full and
before cfail-full (because rfail comes before cfail). The order of tests
seems a little inconsistent, but reordering everywhere would obscure this
commit.
2015-04-26 06:05:38 -07:00
Brian Anderson
0c196fd44c configure: Fix CDPATH bug 2015-04-22 14:52:35 -07:00
Tamir Duberstein
98f4221d49 --enable-debug adds -g. Closes #7205 2015-04-22 07:16:38 -07:00
Tamir Duberstein
0f1bfda006 Alphabetize 2015-04-22 07:16:38 -07:00
Richo Healey
fd69ac160b configure: Turn optimization back on iff --enable-optimize 2015-04-14 00:58:57 -07:00
Richo Healey
87efd2cd74 configure: Set CFG_<FOO>_PROVIDED if it was supplied
This allows you to distinguish between an option that defaulted, and an
option selected by the user
2015-04-14 00:58:51 -07:00
Richo Healey
71a4ea56c2 configure: Don't disable optimizations when enabling debug
Optimization is now on by default. Closes #24405
2015-04-14 00:07:27 -07:00
bors
c897ac04e2 Auto merge of #24177 - alexcrichton:rustdoc, r=aturon
This commit series starts out with more official test harness support for rustdoc tests, and then each commit afterwards adds a test (where appropriate). Each commit should also test and finish independently of all others (they're all pretty separable).

I've uploaded a [copy of the documentation](http://people.mozilla.org/~acrichton/doc/std/) generated after all these commits were applied, and a double check on issues being closed would be greatly appreciated! I'll also browse the docs a bit and make sure nothing regressed too horribly.
2015-04-10 16:18:44 +00:00
Brian Anderson
0e0c841bd5 Nightly gets LLVM assertions 2015-04-09 11:51:46 -07:00
Brian Anderson
a725426ec8 Don't deoptimize llvm when --enable-debug
libLTO fails to link here.
2015-04-08 18:01:46 -07:00
Brian Anderson
6d17c35cd5 configure: Add --enable-debug-jemalloc 2015-04-08 15:12:08 -07:00
Brian Anderson
1002155c75 Add --enable-debug to control multiple perf options 2015-04-08 14:21:36 -07:00
Brian Anderson
7cbf823353 configure: Add --enable-debuginfo 2015-04-08 13:57:37 -07:00
Brian Anderson
8545d2ce53 configure: Disable LLVM asserts by default 2015-04-08 13:27:12 -07:00
Brian Anderson
2cdfd372e2 configure: Clarify help message for --enable-debug-assertions 2015-04-08 13:25:20 -07:00