rust/src/liballoc_jemalloc, branch 1.13.0

Report which required build-time environment variable is not set

2016-09-25T16:18:09+00:00

Add s390x support

2016-09-09T21:28:19+00:00

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

fix cross compilation of std

2016-08-27T06:40:29+00:00

arm-musl targets now use cfg(env = "musl")

2016-07-30T20:39:13+00:00

Add ARM MUSL targets.

2016-07-30T20:39:13+00:00

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).

Update gcc crate dependency to 0.3.27.

2016-07-30T20:39:13+00:00

This is to pull in changes to support ARM MUSL targets. This change also commits a couple of other cargo-generated changes to other dependencies in the various Cargo.toml files.

Fix issue where rustbuild expected msvc to have ar

2016-06-16T12:38:06+00:00

Signed-off-by: Peter Atashian

run rustfmt on liballoc_jemalloc folder

2016-06-05T06:09:17+00:00

rustbuild: Tighten dependencies of build scripts

2016-05-11T06:41:19+00:00

Ensure that `rerun-if-changed` is printed for all build scripts to ensure that they've all got the right list of dependencies.

Fix alloc_jemalloc on windows gnu targets

2016-05-01T12:16:06+00:00

jemalloc prefixes the symbols by default on Windows so we need to account for that to avoid link errors such as: `undefined reference to `mallocx'` when using alloc_jemalloc.