Commit Graph

109 Commits

Author SHA1 Message Date
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 #30776 - 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 #30873 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 #30493 - 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 #30333 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 #30063 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 #29177 - 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
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 #25848 - 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 #25723
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 #21414: ejjeong/aarch64-linux-android
Initial support for aarch64-linux-android (#18920)
- 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 #21065 - 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 #20985: vhbit/ios-install
It was broken as tried to copy dylibs which are actually never been
built for iOS

Fixes #20358
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 #16093

[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