Commit Graph

90 Commits

Author SHA1 Message Date
Alex Crichton
3e12c78172 mk: Fix dependencies of unwind crate on musl
The libunwind.a library was accidentally only being included for the standard
library, not the new unwind crate which implements an unwinder.
2016-05-11 10:47:56 -07:00
Nerijus Arlauskas
b6fc4abe44 Add armv7-linux-androideabi target. 2016-05-07 13:29:57 +03:00
Alex Crichton
126e09e5e5 test: Move run-make tests into compiletest
Forcing them to be embedded in makefiles precludes being able to run them in
rustbuild, and adding them to compiletest gives us a great way to leverage
future enhancements to our "all encompassing test suite runner" as well as just
moving more things into Rust.

All tests are still Makefile-based in the sense that they rely on `make` being
available to run them, but there's no longer any Makefile-trickery to run them
and rustbuild can now run them out of the box as well.
2016-04-28 21:46:40 -07:00
petevine
2ab1f0a850 Use explicit -march flags in the i586 mk file
`-march` should definitely go last, after the environment C(XX)FLAGS, or it's back to square one.
This fixes cross-compilation issues on x86_64.
2016-03-19 00:04:27 +01:00
bors
40c85cd8ae Auto merge of - alexcrichton:old-x86-msvc, r=aturon
rustc: Add an i586-pc-windows-msvc target

Similarly to  where an i586-unknown-linux-gnu target was added, there is
sometimes a desire to compile for x86 Windows as well where SSE2 is disabled.
This commit mirrors the i586-unknown-linux-gnu target and simply adds a variant
for Windows as well.

This is motivated by a recent [Gecko bug][ff] where crashes were seen on 32-bit
Windows due to users having CPUs that don't support SSE2 instructions. It was
requested that we could have non-SSE2 builds of the standard library available
so they could continue to use vanilla releases and nightlies.

[ff]: https://bugzilla.mozilla.org/show_bug.cgi?id=1253202
2016-03-10 22:47:49 -08:00
Alex Crichton
4fbc080033 std: Update jemalloc again to the 4.* track 2016-03-04 09:49:39 -08:00
Alex Crichton
01a2a7f991 rustc: Add an i586-pc-windows-msvc target
Similarly to  where an i586-unknown-linux-gnu target was added, there is
sometimes a desire to compile for x86 Windows as well where SSE2 is disabled.
This commit mirrors the i586-unknown-linux-gnu target and simply adds a variant
for Windows as well.

This is motivated by a recent [Gecko bug][ff] where crashes were seen on 32-bit
Windows due to users having CPUs that don't support SSE2 instructions. It was
requested that we could have non-SSE2 builds of the standard library available
so they could continue to use vanilla releases and nightlies.

[ff]: https://bugzilla.mozilla.org/show_bug.cgi?id=1253202
2016-03-04 09:21:28 -08:00
bors
f59fd46425 Auto merge of - alexcrichton:better-disable-jemallc, r=brson
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-26 13:38:46 +00: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
Manish Goregaokar
db86810a60 Rollup merge of - alexcrichton:armv6-plz, r=brson
Right now the compiler's we're using actually default to armv7/thumb2 I believe,
so this should help push them back to what the arm-unknown-linux-* targets are
for. This at least matches that clang does for the `arm-unknown-linux-gnueabihf`
target which is to map it to an armv6 architecture.

Closes 
2016-02-25 11:41:01 +05:30
petevine
8ddd86a2ab Eradicate last vestiges of armv6 2016-02-22 08:25:29 +01:00
Alex Crichton
d4fda669de mk: Specify armv6 for gcc on arm-unknown-linux-*
Right now the compiler's we're using actually default to armv7/thumb2 I believe,
so this should help push them back to what the arm-unknown-linux-* targets are
for. This at least matches that clang does for the `arm-unknown-linux-gnueabihf`
target which is to map it to an armv6 architecture.

Closes 
2016-02-20 18:21:26 -08:00
petevine
d3ca33fc6e Add a new i586 Linux target 2016-02-13 17:03:00 +01:00
Brian Anderson
bd3fe498e5 Add support for i686-unknown-linux-musl 2016-02-06 20:56:31 +00: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
bors
e3bcddb44b Auto merge of - nbaksalyar:illumos, r=alexcrichton
This pull request adds support for [Illumos](http://illumos.org/)-based operating systems: SmartOS, OpenIndiana, and others. For now it's x86-64 only, as I'm not sure if 32-bit installations are widespread. This PR is based on  by @potatosalad, and also closes , , and .

Required changes in libc are already merged: https://github.com/rust-lang-nursery/libc/pull/138

Here's a snapshot required to build a stage0 compiler:
https://s3-eu-west-1.amazonaws.com/nbaksalyar/rustc-sunos-snapshot.tar.gz
It passes all checks from `make check`.

There are some changes I'm not quite sure about, e.g. macro usage in `src/libstd/num/f64.rs` and `DirEntry` structure in `src/libstd/sys/unix/fs.rs`, so any comments on how to rewrite it better would be greatly appreciated.

Also, LLVM configure script might need to be patched to build it successfully, or a pre-built libLLVM should be used. Some details can be found here: https://llvm.org/bugs/show_bug.cgi?id=25409

Thanks!

r? @brson
2016-02-03 22:40:32 +00:00
Alex Crichton
178d4b0fd3 Revert "mk: fix some undefined variable warnings"
This reverts commit d03712977d.
2016-02-01 23:27:04 -08:00
bors
7cae6b59b4 Auto merge of - tamird:fix-makefile-bugs, r=alexcrichton
Some of this is scary stuff. Probably time to lint against this.

Found with `make --warn-undefined-variables`.

r? @alexcrichton
2016-02-01 18:27:54 +00:00
bors
91e804409b Auto merge of - alexcrichton:mips-warnings, r=aturon
Currently any compilation to MIPS spits out the warning:

    'generic' is not a recognized processor for this target (ignoring processor)

Doesn't make for a great user experience! We don't encounter this in the normal
bootstrap because the cpu/feature set are set by the makefiles. Instead let's
just propagate these to the defaults for the entire target all the time (still
overridable from the command line) and prevent warnings from being emitted by
default.
2016-02-01 12:24:01 +00:00
Tamir Duberstein
d03712977d mk: fix some undefined variable warnings
Some of this is scary stuff. Probably time to lint against this.

Found with `make --warn-undefined-variables`.
2016-02-01 05:21:06 -05:00
petevine
2efd024ad3 Fix the armv7 linux target 2016-01-31 22:26:34 +01:00
Nikita Baksalyar
f189d7a693
Add Illumos support 2016-01-31 18:57:26 +03:00
bors
9041b93058 Auto merge of - 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
Jorge Aparicio
64ac041b1f rustc: set MIPS cpu/features in the compiler
cf 
2016-01-30 14:44:40 -05:00
Jorge Aparicio
146dfce803 revert changes used for local testing 2016-01-30 14:44:38 -05:00
Alex Crichton
0316013b49 rustc: Set MIPS cpu/features in the compiler
Currently any compilation to MIPS spits out the warning:

    'generic' is not a recognized processor for this target (ignoring processor)

Doesn't make for a great user experience! We don't encounter this in the normal
bootstrap because the cpu/feature set are set by the makefiles. Instead let's
just propagate these to the defaults for the entire target all the time (still
overridable from the command line) and prevent warnings from being emitted by
default.
2016-01-29 23:44:46 -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
Alex Crichton
ea31ff20f0 mk: Fix cross-compiling to armv7-unknown-linux-gnu
The cross prefix was not likely the actual compiler that needed to be used, but
rather the standard `arm-linux-gnueabihf-gcc` compiler can just be used with
`-march=armv7`.
2016-01-29 12:36:45 -08:00
Alex Crichton
7e1acc57d8 mk: Fix compiling jemalloc for powerpc64
We forgot to pass down the `-m64` flag to gcc, so we were actually compiling
powerpc code which would then later fail to link!
2016-01-29 12:23:17 -08:00
Manish Goregaokar
7a0e490bdd Rollup merge of - alexcrichton:fix-powerpc64-cross-prefix, r=brson
Looks like the way to create these executables is to use the standard
`powerpc-linux-gnu-gcc` compiler but with the `-m64` option.
2016-01-29 20:19:39 +05:30
Manish Goregaokar
cbfc5e3704 Rollup merge of - alexcrichton:ios-old-mac, r=brson
Unfortunately older clang compilers don't support this argument, so the
bootstrap will fail. We don't actually really need to optimized the C code we
compile, however, as currently we're just compiling jemalloc and not much else.
2016-01-29 20:19:38 +05:30
Alex Crichton
ba97b06609 mk: Fix cross prefix for powerpc64
Looks like the way to create these executables is to use the standard
`powerpc-linux-gnu-gcc` compiler but with the `-m64` option.
2016-01-28 21:50:29 -08:00
Fabrice Desré
63b4639691 Add support for armv7 toolchains 2016-01-28 09:45:56 -08:00
Alex Crichton
1a910a0ff3 mk: Remove the -mfpu=vfp4 argument from arm iOS
Unfortunately older clang compilers don't support this argument, so the
bootstrap will fail. We don't actually really need to optimized the C code we
compile, however, as currently we're just compiling jemalloc and not much else.
2016-01-27 22:34:26 -08:00
Manish Goregaokar
7208d25003 Rollup merge of - antonblanchard:powerpc64_merge, r=alexcrichton
This adds support for big endian and little endian PowerPC64.
make check runs clean apart from one big endian backtrace issue.
2016-01-15 17:28:28 +05:30
Dave Huseby
a933526fc4 Fixes 2016-01-13 11:25:01 -08: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
Jörg Krause
035a0933f8 Fix arm-unknown-linux-gnueabi floating-point ABI
gnueabi indicates soft whereas gnueabihf indicates hard floating-point ABI.
2016-01-09 14:25:02 +01:00
bors
29e60aba7d Auto merge of - semarie:openbsd-cc, r=alexcrichton
this PR reverts previous ones, that tried to make `cc` to found `estdc++` in `/usr/local/lib`. It causes more trouble than it resolvs things: rustc become unbuildable if another version already exists in `/usr/local` (for example, `libstd-xxxx.so` is found in `/usr/local/lib` and in builddir).

so this PR tries another way to achieve build, but using the good linker for building. By default, rustc use `cc` for linking. But under OpenBSD, `cc` is gcc 4.2.1 from base, whereas we build with gcc 4.9 from ports. By linking using the compiler found at compile-time, we ensure that the compiler will found his own stdc++ library without trouble.

r? @alexcrichton
2015-12-21 04:15:28 +00:00
Sébastien Marie
b74359a0a0 openbsd: use specific linker for building
By default, rustc use `cc` as linker. Under OpenBSD, `cc` is gcc version 4.2.1.
So use the compiler found at configure-time for linking: it will be gcc 4.9.

It permits to resolv problem of finding -lestdc++ or -lgcc. For base gcc (4.2), there are in not standard path, whereas for ports gcc (4.9) there are in standard path.
2015-12-20 07:21:36 +01: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
Dave Huseby
0c491e86f0 Fixes by removing the -arch i386 form the right spot 2015-12-11 10:53:04 -08:00
Felix S. Klock II
31d383fcd2 Remove STARTUP_OBJS from Makefile deps for non win-gnu targets.
The `rsbegin.o` and `rsend.o` build products should not be generated
on non WinGnu platforms.

This is another path to resolving  for non win-gnu targets.
(And it won't require a snapshot, unlike PR #30208.)
2015-12-08 14:56:22 +01:00
Vadim Chugunov
9f9afe5769 Make sure rsbegin.o and rsend.o get packaged with target lib artifacts.
Also, unified libc startup objects finding logic with that of the `-musl` target, since conceptually they were doing the same thing.
2015-11-07 17:56:55 -08:00
bors
71409184dc Auto merge of - vadimcn:rtstuff, r=alexcrichton
Note: for now, this change only affects `-windows-gnu` builds.

So why was this `libgcc` dylib dependency needed in the first place?
The stack unwinder needs to know about locations of unwind tables of all the modules loaded in the current process.  The easiest portable way of achieving this is to have each module register itself with the unwinder when loaded into the process.  All modules compiled by GCC do this by calling the __register_frame_info() in their startup code (that's `crtbegin.o` and `crtend.o`, which are automatically linked into any gcc output).
Another important piece is that there should be only one copy of the unwinder (and thus unwind tables registry) in the process.  This pretty much means that the unwinder must be in a shared library (unless everything is statically linked). 

Now, Rust compiler tries very hard to make sure that any given Rust crate appears in the final output just once.   So if we link the unwinder statically to one of Rust's crates, everything should be fine.

Unfortunately, GCC startup objects are built under assumption that `libgcc` is the one true place for the unwind info registry, so I couldn't find any better way than to replace them.  So out go `crtbegin`/`crtend`, in come `rsbegin`/`rsend`!  

A side benefit of this change is that rustc is now more in control of the command line that goes to the linker, so we could stop using `gcc` as the linker driver and just invoke `ld` directly.
2015-11-01 17:15:29 +00:00
Vadim Chugunov
bd0cf1ba13 Don't use GCC's startup objects (crtbegin.o/crtend.o); build and use our own (for now on for -windows-gnu target only).
Since it isn't possible to disable linkage of just GCC startup objects, we now need logic for finding libc installation directory and copying the required startup files (e.g. crt2.o) to rustlib directory.
Bonus change: use the `-nodefaultlibs` flag on Windows, thus paving the way to direct linker invocation.
2015-10-19 00:42:04 -07:00
Alex Crichton
4fe5932e3a mk: Fix compile for mips
* Don't pass `-mno-compact-eh`, apparently not all compilers have this?
* Don't pass `+o32`, apparently LLVm doesn't recognize this
* Use `mipsel-linux-gnu` as a prefix instead of `mipsel-unknown-linux-gnu`, this
  matches the ubuntu package at least!
2015-10-16 14:30:56 -07: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
Sebastian Wicki
318cd843d1 Various fixes for NetBSD/amd64 2015-09-21 21:50:54 +02: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