- 17 6月, 2014 1 次提交
-
-
由 Alex Crichton 提交于
-
- 14 6月, 2014 2 次提交
-
-
由 Daniel Micay 提交于
Rust no longer has support for JIT compilation, so it doesn't currently require a PaX MPROTECT exception. The extended attributes are preferred over modifying the binaries so it's not actually going to work on most systems like this anyway. If JIT compilation ends up being supported again, it should handle this by *always* applying the exception via an extended attribute without performing auto-detection of PaX on the host. The `paxctl` tool is only necessary with the older method involving modifying the ELF binary.
-
由 Alex Crichton 提交于
If the compiler is built with --{llvm,jemalloc,libuv}-root, then the configure script can skip updating these submodules. Closes #14822
-
- 12 6月, 2014 2 次提交
-
-
由 Alex Crichton 提交于
Closes #5563
-
由 Alex Crichton 提交于
This adds a new configure option, --jemalloc-root, which will specify a location at which libjemalloc_pic.a must live. This library is then used for the build triple as the jemalloc library to link.
-
- 05 6月, 2014 1 次提交
-
-
由 Sylvestre Ledru 提交于
Remove a warning (./configure: 1140: [: unexpected operator) when built with --disable-manage-submodules
-
- 29 5月, 2014 1 次提交
-
-
由 Luqman Aden 提交于
-
- 28 5月, 2014 3 次提交
-
-
由 Richo Healey 提交于
-
由 Richo Healey 提交于
-
由 Richo Healey 提交于
-
- 27 5月, 2014 1 次提交
-
-
由 OGINO Masanori 提交于
Signed-off-by: NOGINO Masanori <masanori.ogino@gmail.com>
-
- 21 5月, 2014 1 次提交
-
-
由 Felix S. Klock II 提交于
I mostly tried to remain backwards compatible with old invocations of the `configure` script; if you do not want to use `CC` et al., you should not have to; you can keep using `--enable-clang` and/or `--enable-ccache`. The overall intention is to capture the following precedences for guessing the C compiler: 1. Value of `CC` at make invocation time. 2. Value of `CC` at configure invocation time. 3. Compiler inferred at configure invocation time (`gcc` or `clang`). The strategy is to check (at `configure` time) if each of the environment variables is set, and if so, save its value in a corresponding `CFG_` variable (e.g. `CFG_CC`). Then, in the makefiles, if `CC` is not set but `CFG_CC` is, then we use the `CFG_CC` setting as `CC`. Also, I fold the potential user-provided `CFLAGS` and `CXXFLAGS` values into all of the per-platform `CFLAGS` and `CXXFLAGS` settings. (This was opposed to adding `$(CFLAGS)` in an ad-hoc manner to various parts of the mk files.) Fix #13805. ---- Note that if you try to set the compiler to clang via the `CC` and `CXX` environment variables, you will probably need to also set `CXXFLAGS` to `--enable-libcpp` so that LLVM will be configured properly. ---- Introduce CFG_USING_CLANG, which is distinguished from CFG_ENABLE_CLANG because the former represents "we think we're using clang, choose appropriate warning-control options" while the latter represents "we asked configure (or the host required) that we attempt to use clang, so check that we have an appropriate version of clang." The main reason I added this is that I wanted to allow the user to choose clang via setting the `CC` environment variable, but I did not want that method of selection to get confused with the user passing the `--enable-clang` option. ---- A digression: The `configure` script does not infer the compiler setting if `CC` is set; but if `--enable-clang` was passed, then it *does* still attempt to validate that the clang version is compatible. Supporting this required revising `CLANG_VERSION` check to be robust in face of user-provided `CC` value. In particular, on Travis, the `CC` is set to `gcc` and so the natural thing to do is to attempt to use `gcc` as the compiler, but Travis is also passing `--enable-clang` to configure. So, what is the right answer in the face of these contradictory requests? One approach would be to have `--enable-clang` supersede the setting for `CC` (and instead just call whatever we inferred for `CFG_CLANG`). That sounds maximally inflexible to me (pnkfelix): a developer requesting a `CC` value probably wants it respected, and should be able to set it to something else; it is harder for that developer to hack our configure script to change its inferred path to clang. A second approach would be to blindly use the `CC` value but keep going through the clang version check when `--enable-clang` is turned on. But on Travis (a Linux host), the `gcc` invocation won't print a clang version, so we would not get past the CLANG_VERSION check in that context. A third approach would be to never run the CLANG_VERSION check if `CC` is explicitly set. That is not a terrible idea; but if the user uses `CC` to pass in a path to some other version of clang that they want to test, probably should still send that through the `CLANG_VERSION` check. So in the end I (pnkfelix) took a fourth approach: do the CLANG_VERSION check if `CC` is unset *or* if `CC` is set to a string ending with `clang`. This way setting `CC` to things like `path/to/clang` or `ccache clang` will still go through the CLANG_VERSION check, while setting `CC` to `gcc` or some unknown compiler will skip the CLANG_VERSION check (regardless of whether the user passed --enable-clang to `configure`). ---- Drive-by fixes: * The call that sets `CFG_CLANG_VERSION` was quoting `"$CFG_CC"` in its invocation, but that does not play nicely with someone who sets `$CFG_CC` to e.g. `ccache clang`, since you do not want to intepret that whole string as a command. (On the other hand, a path with spaces might need the quoted invocation. Not sure which one of these corner use-cases is more important to support.) * Fix chk_cc error message to point user at `gcc` not `cc`.
-
- 11 5月, 2014 1 次提交
-
-
由 Daniel Micay 提交于
This adds a `std::rt::heap` module with a nice allocator API. It's a step towards fixing #13094 and is a starting point for working on a generic allocator trait. The revision used for the jemalloc submodule is the stable 3.6.0 release. Closes #11807
-
- 08 5月, 2014 1 次提交
-
-
由 Michael Woerister 提交于
-
- 29 4月, 2014 1 次提交
-
-
由 Alex Crichton 提交于
Compile-fail tests for syntax extensions belong in this suite which has correct dependencies on all artifacts rather than just the target artifacts. Closes #13818
-
- 18 4月, 2014 4 次提交
-
-
由 Alex Crichton 提交于
The goal of the snapshot bots is to produce binaries which can run in as many locations as possible. Currently we build on Centos 6 for this reason, but with LLVM's update to C++11, this reduces the number of platforms that we could possibly run on. This adds a --enable-llvm-static-stdcpp option to the ./configure script for Rust which will enable building a librustc with a static dependence on libstdc++. This normally isn't necessary, but this option can be used on the snapshot builders in order to continue to make binaries which should be able to run in as many locations as possible.
-
由 Alex Crichton 提交于
OSX often has a more recent version of clang than it does for GCC. When an older version of gcc is detected on OSX, the --enable-clang flag is implicitly enabled.
-
由 Alex Crichton 提交于
When clang is enabled, also pass through --enable-libcpp to LLVM's configure command line to help it pick up the most recent c++ runtime library. This also changes the mklldeps.py script to pick up on whether LLVM was linked against stdc++ or c++ based on the --cxxflags that llvm-config prints. In an ongoing attempt to update LLVM, the bots need to update their C compilers to something that supports c++11 (LLVM recently switched). The OSX bots are running Lion (10.7), which only supports up to gcc 4.2 and clang 3.2. Apparently the libstdc++ is too old (even on the most updated command line tools) for LLVM, but using libc++ instead appears to work just fine.
-
由 Alex Crichton 提交于
This comes with a number of fixes to be compatible with upstream LLVM: * Previously all monomorphizations of "mem::size_of()" would receive the same symbol. In the past LLVM would silently rename duplicated symbols, but it appears to now be dropping the duplicate symbols and functions now. The symbol names of monomorphized functions are now no longer solely based on the type of the function, but rather the type and the unique hash for the monomorphization. * Split stacks are no longer a global feature controlled by a flag in LLVM. Instead, they are opt-in on a per-function basis through a function attribute. The rust #[no_split_stack] attribute will disable this, otherwise all functions have #[split_stack] attached to them. * The compare and swap instruction now takes two atomic orderings, one for the successful case and one for the failure case. LLVM internally has an implementation of calculating the appropriate failure ordering given a particular success ordering (previously only a success ordering was specified), and I copied that into the intrinsic translation so the failure ordering isn't supplied on a source level for now. * Minor tweaks to LLVM's API in terms of debuginfo, naming, c++11 conventions, etc.
-
- 31 3月, 2014 1 次提交
-
-
由 Alex Crichton 提交于
The previous regex was a bit to strict, rejecting versions such as 3.4.1 which is apparently the version which travis is currently installing, causing all travis builds to fail.
-
- 30 3月, 2014 1 次提交
-
-
由 klutzy 提交于
MSYS2 supports `MINGW64` system for 64-bit environment. It sets `MSYSTEM=MINGW64` environment variable, which changes output of `uname -s` thus affects `configure` behavior. This patch adds `MINGW64*` support for `configure`.
-
- 29 3月, 2014 2 次提交
-
-
由 Michael Darakananda 提交于
-
由 Brian Anderson 提交于
Another sanity check. Can be disabled in `install.sh` via `--disable-verify` and `configure` with `--disable-verify-install`.
-
- 26 3月, 2014 2 次提交
-
-
由 Brian Anderson 提交于
-
由 Brian Anderson 提交于
Trying to reduce the complexity of installation
-
- 10 3月, 2014 3 次提交
-
-
由 Brian Anderson 提交于
-
由 Brian Anderson 提交于
-
由 Adrien Tétar 提交于
-
- 09 3月, 2014 1 次提交
-
-
由 Adrien Tétar 提交于
`prep.js` outputs its own HTML directives, which `pandoc` cannot recognize when converting the document into LaTeX (this is why the PDF docs have never been highlighted as of now). Note that if we were to add the `.rust` class to snippets, we could probably use pandoc's native highlighting capatibilities i.e. Kate.
-
- 25 2月, 2014 1 次提交
-
-
由 Gary M. Josack 提交于
std::condition was removed in 454882dc but there are still links to the guide. Removing them.
-
- 21 2月, 2014 2 次提交
-
-
由 Alex Crichton 提交于
This is the current head of LLVM, and we can indeed build with 3.5
-
由 Alex Crichton 提交于
This is the current head of LLVM, and we can indeed build with 3.5
-
- 15 2月, 2014 3 次提交
-
-
由 Brian Anderson 提交于
-
由 Brian Anderson 提交于
-
由 Brian Anderson 提交于
This way of doing snapshots hasn't been used since 2011.
-
- 30 1月, 2014 1 次提交
-
-
由 Alex Crichton 提交于
This upgrade brings commit by @EddyB to help optimizations of virtual calls in a few places (https://github.com/llvm-mirror/llvm/commit/6d2bd95) as well as a commit by @c-a to *greatly* improve the runtime of the optimization passes (https://github.com/rust-lang/llvm/pull/3). Nice work to these guys!
-
- 25 1月, 2014 1 次提交
-
-
由 Alex Crichton 提交于
By default, the compiler and libraries are all still built with rpaths, but this can be opted out of with --disable-rpath to ./configure or --no-rpath to rustc. cc #5219
-
- 16 1月, 2014 1 次提交
-
-
由 Alex Crichton 提交于
We'll use this when building snapshots so we can upgrade freely, but all compilers will inject a version by default.
-
- 15 1月, 2014 1 次提交
-
-
由 Derek Guenther 提交于
-
- 14 1月, 2014 1 次提交
-
-
由 Alex Crichton 提交于
-