Commit Graph

41 Commits

Author SHA1 Message Date
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
Alex Crichton
938099a7eb Register new snapshots
* Lots of core prelude imports removed
* Makefile support for MSVC env vars and Rust crates removed
* Makefile support for morestack removed
2015-08-11 15:11:13 -07:00
Mark Buer
33a7e67904 Splits Android NDK path configuration. 2015-07-28 19:21:04 +12:00
Dave Huseby
1a928f434a adding support for i686-unknown-freebsd target 2015-07-11 00:23:04 -07: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
Alex Crichton
1ec520a531 mk: Move logic out of MSVC's 64-bit cfg makefile
This logic applies to all MSVC targets, so instead refactor it into platform.mk
so it can one day apply to 32-bit MSVC.
2015-06-25 09:20:12 -07:00
Aidan Hobson Sayers
5ef250427d musl only uses rlib files for stdlib linking 2015-06-14 16:18:51 +01:00
Alex Crichton
6fee2690cf mk: Tweak the LIB_GLOB for MSVC
Right now the distribution tarball for MSVC only includes the *.dll files for
the supporting libraries, but not the corresponding *.lib files which allow
actually linking to the dll. This means that the current MSVC nightlies cannot
produce dynamically linked binaries as the *.lib files are not available to link
against.

This commit modifies the `LIB_GLOB` used to copy the files around to include the
`lib` variant of the `dll`.
2015-06-11 14:15:36 -07:00
Alex Crichton
cb7d914880 mk: Compile C code on MSVC with /MD
On MSVC there are two ways that the CRT can be linked, either statically or
dynamically. Each object file produced by the compiler is compiled against
msvcrt (a dll) or libcmt (a static library). When the linker is dealing with
more than one object file, it requires that all object files link to the same
CRT, or else the linker will spit out some errors.

For now, compile code with `-MD` as it seems to appear more often in C libraries
so we'll stick with the same trend.
2015-06-03 15:24:35 -07:00
bors
f14190199c Auto merge of - alexcrichton:fix-msvc, r=brson
Now that MSVC support has landed in the most recent nightlies we can now have
MSVC bootstrap itself without going through a GNU compiler first. Unfortunately,
however, the bootstrap currently fails due to the compiler not being able to
find the llvm-ar.exe tool during the stage0 libcore compile. The compiler cannot
find this tool because it's looking inside a directory that does not exist:

    $SYSROOT/rustlib/x86_64-pc-windows-gnu/bin

The `gnu` on this triple is because the bootstrap compiler's host architecture
is GNU. The build system, however, only arranges for the llvm-ar.exe tool to be
available in this location:

    $SYSROOT/rustlib/x86_64-pc-windows-msvc/bin

To resolve this discrepancy, the build system has been modified to understand
triples that are bootstrapped from another triple, and in this case copy the
native tools to the right location.
2015-06-02 05:12:51 +00:00
Alex Crichton
b8c59211ed mk: Fix MSVC bootstrapping itself
Now that MSVC support has landed in the most recent nightlies we can now have
MSVC bootstrap itself without going through a GNU compiler first. Unfortunately,
however, the bootstrap currently fails due to the compiler not being able to
find the llvm-ar.exe tool during the stage0 libcore compile. The compiler cannot
find this tool because it's looking inside a directory that does not exist:

    $SYSROOT/rustlib/x86_64-pc-windows-gnu/bin

The `gnu` on this triple is because the bootstrap compiler's host architecture
is GNU. The build system, however, only arranges for the llvm-ar.exe tool to be
available in this location:

    $SYSROOT/rustlib/x86_64-pc-windows-msvc/bin

To resolve this discrepancy, the build system has been modified to understand
triples that are bootstrapped from another triple, and in this case copy the
native tools to the right location.
2015-05-27 19:36:28 -07:00
Alex Crichton
bc7c62de6d mk: Ensure LINK_$(1) is defined for all targets
The changes scaled back in 4cc025d8 were a little too aggressive and broke a
bunch of cross compilations by not defining the `LINK_$(1)` variable for all
targets. This commit ensures that the variable is defined for all targets by
defaulting it to the normal compiler if it's not already defined (it's only
defined specially for MSVC).

Closes 
2015-05-26 10:05:46 -07:00
Brian Anderson
1cda3236c9 Specify linkers for cross-compile scenarios
The recent MSVC patch made the build system pass explicit linkers to
rustc, but did not set that up for anything other than MSVC.
2015-05-22 14:56:41 -07:00
Alex Crichton
cb3071b273 mk: Update make dist for MSVC targets
This commit updates the `dist` target for MSVC to not build the mingw components
and to also ensure that the `llvm-ar.exe` binary is ferried along into the right
location for installs.
2015-05-19 10:53:07 -07:00
Alex Crichton
b538189ba0 mk: Generate a .def file for rustc_llvm on MSVC
Windows needs explicit exports of functions from DLLs but LLVM does not mention
any of its symbols as being export-able from a DLL. The compiler, however,
relies on being able to use LLVM symbols across DLL boundaries so we need to
force many of LLVM's symbols to be exported from `rustc_llvm.dll`. This commit
adds support for generation of a `rustc_llvm.def` file which is passed along to
the linker when generating `rustc_llvm.dll` which should keep all these symbols
exportable and usable.
2015-05-19 10:53:07 -07:00
Alex Crichton
a4ef308473 mk: Add the ability to depend on native LLVM tools
The compiler will require that `llvm-ar.exe` be available for MSVC-targeting
builds (more comments on this soon), so this commit adds support for targets to
depend on LLVM tools. The `core` library for MSVC depends on `llvm-ar.exe` which
will be copied into place for the target before the compiler starts to run.

Note that these targets all depend on `llvm-config.exe` to ensure that they're
built before they're attempted to be copied.
2015-05-19 10:53:04 -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
Alex Crichton
4cc025d83c Scale back changes made 2015-05-12 14:50:36 -07: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
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
Alex Crichton
681fc82456 mk: Remove a bunch of unused directives 2015-04-27 09:22:05 -07:00
Tamir Duberstein
d51047ded0 Strip all leading/trailing newlines 2015-03-15 09:08:21 -07:00
Dave Huseby
cd8f31759f bitrig integration 2015-02-11 14:49:06 -08:00
Sébastien Marie
fcb30a0b67 openbsd support 2015-02-01 14:41:38 +01:00
Alex Crichton
a6780d8c6b rollup merge of : ejjeong/aarch64-linux-android
Initial support for aarch64-linux-android ()
- Add new configuration files
- Modify some options to compile & link succesfully.
  (PIE, disable tls on jemalloc, modify some external function linkage, ..)
- To build, refer to https://github.com/rust-lang/rust/wiki/Doc-building-for-android.
   (tested with platform=21 and toolchain=aarch64-linux-android-4.9)
2015-01-21 09:15:59 -08:00
bors
710dcdc2eb Auto merge of - ColonelJ:master, r=brson
Removed use of unused LDPATH variable on Windows as is done for other platforms, and added GCC flag to ensure MINGW's ANSI compatible STDIO functions are used wherever available (required by jemalloc).

Without these changes it ends up setting the PATH twice, and the second time the PATH begins with `:` which is invalid.  Also the regular msvcrt printf-like functions would be used which don't understand stuff like %hhd and %z which jemalloc uses.

This change ought not to make any difference to the output but it fixes the build process for me since at least my build environment couldn't handle that broken path caused by LDPATH being empty.
2015-01-21 03:54:21 +00:00
Eunji Jeong
940080501b Initial support for aarch64-linux-android 2015-01-20 17:43:15 +09:00
Alex Crichton
73149be578 rollup merge of : vhbit/ios-install
It was broken as tried to copy dylibs which are actually never been
built for iOS

Fixes 
2015-01-15 14:11:29 -08:00
KernelJ
f071f3b185 Fixes to cfg .mk files for Windows: removed use of unused LDPATH variable on Windows as is done for other platforms, and added GCC flag to ensure MINGW's ANSI compatible STDIO functions are used wherever available (required by jemalloc). 2015-01-12 23:26:22 +00:00
Valerii Hiora
11737a3e1d iOS: fixed install phase
It was broken as tried to copy dylibs which are actually never been
built for iOS
2015-01-12 10:09:47 +02:00
Richo Healey
f512dce713 powerpc: Add platform configuration 2015-01-11 21:14:30 -08:00
Valerii Hiora
577d0dbcb8 iOS: preliminary 64-bit archs support 2015-01-09 18:38:30 +02:00
Valerii Hiora
a945f288ff iOS: makefiles and runtime for new archs 2015-01-09 18:38:30 +02:00
Akos Kiss
6e5fb8bd1b Initial version of AArch64 support.
Adds AArch64 knowledge to:
* configure,
* make files,
* sources,
* tests, and
* documentation.
2015-01-03 15:16:10 +00:00
Michael Neumann
25c1bfe175 Several fixes for DragonFly (rebase) 2014-12-19 13:05:06 +01:00
Cody P Schafer
8581f00249 mk/cfg: add .mk suffix on files to avoid "supprises" when backup files (file~) are in the directory 2014-11-19 16:00:51 -05:00
Cody P Schafer
61e53c94f2 CFG_CFLAGS is only used for jemalloc, rename all uses to CFG_JEMALLOC_CFLAGS
i386-apple-ios already used CFG_JEMALLOC_CFLAGS, so merge that one
2014-11-17 16:41:09 -05:00
klutzy
1df6be1926 mk: Fix Windows cross-build prefix 2014-11-09 04:26:18 +09:00
Corey Richardson
6b130e3dd9 Implement flexible target specification
Removes all target-specific knowledge from rustc. Some targets have changed
during this, but none of these should be very visible outside of
cross-compilation. The changes make our targets more consistent.

iX86-unknown-linux-gnu is now only available as i686-unknown-linux-gnu. We
used to accept any value of X greater than 1. i686 was released in 1995, and
should encompass the bare minimum of what Rust supports on x86 CPUs.

The only two windows targets are now i686-pc-windows-gnu and
x86_64-pc-windows-gnu.

The iOS target has been renamed from arm-apple-ios to arm-apple-darwin.

A complete list of the targets we accept now:

arm-apple-darwin
arm-linux-androideabi
arm-unknown-linux-gnueabi
arm-unknown-linux-gnueabihf

i686-apple-darwin
i686-pc-windows-gnu
i686-unknown-freebsd
i686-unknown-linux-gnu

mips-unknown-linux-gnu
mipsel-unknown-linux-gnu

x86_64-apple-darwin
x86_64-unknown-freebsd
x86_64-unknown-linux-gnu
x86_64-pc-windows-gnu

Closes 

[breaking-change]
2014-11-04 05:07:47 -05:00
Cody P Schafer
f3fd79d6aa split platform definitions out of mk/platform.mk
The goal here is to make it easier to add new platform definitions,
especially when the additions are programmatic (ie: in build scripts).
2014-10-25 21:01:18 -04:00