- 03 1月, 2015 2 次提交
-
-
由 Akos Kiss 提交于
Adds AArch64 knowledge to: * configure, * make files, * sources, * tests, and * documentation.
-
由 Brian Anderson 提交于
-
- 31 12月, 2014 2 次提交
-
-
由 Brian Anderson 提交于
-
由 Michael Woerister 提交于
-
- 30 12月, 2014 2 次提交
-
-
由 Brian Anderson 提交于
-
由 Brian Anderson 提交于
-
- 26 11月, 2014 1 次提交
-
-
由 Michael Woerister 提交于
-
- 21 11月, 2014 1 次提交
-
-
由 Cody P Schafer 提交于
We add CFG_LLVM_TARGET_$(target) (which can be defined in any of the mk/cfg/* files) and supply a default to the plain target name CFG_LLVM_TARGET mirrors the value of llvm_target (aka llvm-target) in the librustc_back runtime target specification.
-
- 16 11月, 2014 1 次提交
-
-
由 Jauhien Piatlicki 提交于
not in hardcoded libdir path. If there was no LIBDIR provided during configuration fallback to hardcoded paths. Thanks to Jan Niklas Hasse for solution and to Alex Crichton for improvements. Closes #11671
-
- 11 11月, 2014 1 次提交
-
-
由 Brian Anderson 提交于
Commit bec2ee77 started quoting paths discovered as part of the `probe` function, which includes git. The `make` `wildcard` function appears to be incompatible with quoted paths so this check in the makefile now fails. Employing `wildcard` here appears to only re-verify that git actually exists, which the configure script already did, so I've just removed it. Additionally, with the quoted paths the `subst` function should no longer be needed, so I've removed it as well. Closes #18771
-
- 07 11月, 2014 1 次提交
-
-
由 Alex Crichton 提交于
Right now the windows nightlies are failing because they're encountering a linker error when producing stage3 libs. The stage3 libs aren't actually used in general, and we primarily just want to generate a static stage3 binary, not static stage3 dylibs.
-
- 04 11月, 2014 2 次提交
-
-
由 Corey Richardson 提交于
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]
-
由 Alex Crichton 提交于
If a dylib is being produced, the compiler will now first check to see if it can be created entirely statically before falling back to dynamic dependencies. This behavior can be overridden with `-C prefer-dynamic`. Due to the alteration in behavior, this is a breaking change. Any previous users relying on dylibs implicitly maximizing dynamic dependencies should start passing `-C prefer-dynamic` to compilations. Closes #18499 [breaking-change]
-
- 03 11月, 2014 1 次提交
-
-
由 Steven Fackler 提交于
-
- 29 10月, 2014 1 次提交
-
-
由 Daniel Micay 提交于
This reverts commit c245c5bb. Parallel code generation generates invalid code for librand, which is caught by recent versions of binutils.
-
- 23 10月, 2014 2 次提交
-
-
由 Nick Cameron 提交于
-
由 Nick Cameron 提交于
Closes #16914
-
- 22 10月, 2014 1 次提交
-
-
由 Stuart Pernsteiner 提交于
Enable parallel codegen (2 units) by default when --opt-level is 0 or 1. This gives a minor speedup on large crates (~10%), with only a tiny slowdown (~2%) for small ones (which usually build in under a second regardless). The current default (no parallelization) is used when the user requests optimization (--opt-level 2 or 3), and when the user has enabled LTO (which is incompatible with parallel codegen). This commit also changes the rust build system to use parallel codegen when appropriate. This means codegen-units=4 for stage0 always, and also for stage1 and stage2 when configured with --disable-optimize. (Other settings use codegen-units=1 for stage1 and stage2, to get maximum performance for release binaries.) The build system also sets codegen-units=1 for compiletest tests (compiletest does its own parallelization) and uses the same setting as stage2 for crate tests.
-
- 10 10月, 2014 1 次提交
-
-
由 Brian Anderson 提交于
-
- 05 10月, 2014 1 次提交
-
-
由 Luqman Aden 提交于
-
- 26 9月, 2014 1 次提交
-
-
由 Brian Anderson 提交于
This is more consistent with how the other channels work.
-
- 16 9月, 2014 1 次提交
-
-
由 Brian Anderson 提交于
Adds a new configure flag, --release-channel, which determines how the version number should be augmented with a release label, as well as how the distribution artifacts will be named. This is entirely for use by the build automation. --release-channel can be either 'source', 'nightly', 'beta', or 'stable'. Here's a summary of the affect of these values on version number and artifact naming, respectively: * source - '0.12.0-pre', 'rust-0.12.0-pre-...' * nightly - '0.12.0-nightly', 'rust-nightly-...' * beta - '0.12.0-beta', 'rust-beta-...' * stable - '0.12.0', 'rust-0.12.0-...' Per http://discuss.rust-lang.org/t/rfc-impending-changes-to-the-release-process/508/1
-
- 08 9月, 2014 1 次提交
-
-
由 Daniel Micay 提交于
The performance hit from these checks is significant, but unoptimized builds are already incredibly slow. Enabling these checks results in better test coverage since there are bots doing unoptimized builds, and the cost is relatively small in the context of an unoptimized build. This also allows using `JEMALLOC_FLAGS` to override the default configure flags.
-
- 09 8月, 2014 1 次提交
-
-
由 Brian Anderson 提交于
Reduces time to build stage0 from 11:30 to 9:40 on my machine.
-
- 23 7月, 2014 2 次提交
-
-
由 Birunthan Mohanathas 提交于
-
由 Birunthan Mohanathas 提交于
-
- 22 7月, 2014 1 次提交
-
-
由 Alex Crichton 提交于
The long hash just takes up space and you can discover the main hash through the `rustc --version verbose` command.
-
- 16 7月, 2014 1 次提交
-
-
由 klutzy 提交于
-
- 12 7月, 2014 1 次提交
-
-
由 Brian Anderson 提交于
-
- 06 7月, 2014 1 次提交
-
-
由 Alex Crichton 提交于
The compiler will no longer insert a hash or version into a filename by default. Instead, all output is simply based off the crate name being compiled. For example, a crate name of `foo` would produce the following outputs: * bin => foo * rlib => libfoo.rlib * dylib => libfoo.{so,dylib} or foo.dll * staticlib => libfoo.a The old behavior has been moved behind a new codegen flag, `-C extra-filename=<hash>`. For example, with the "extra filename" of `bar` and a crate name of `foo`, the following outputs would be generated: * bin => foo (same old behavior) * rlib => libfoobar.rlib * dylib => libfoobar.{so,dylib} or foobar.dll * staticlib => libfoobar.a The makefiles have been altered to pass a hash by default to invocations of `rustc` so all installed rust libraries will have a hash in their filename. This is done because the standard libraries are intended to be installed into privileged directories such as /usr/local. Additionally, it involves very few build system changes! RFC: 0035-remove-crate-id [breaking-change]
-
- 28 6月, 2014 1 次提交
-
-
由 Alex Crichton 提交于
-
- 25 6月, 2014 1 次提交
-
-
由 Robert Buonpastore 提交于
-
- 17 6月, 2014 2 次提交
-
-
由 Alex Crichton 提交于
This commit disables rustc's emission of rpath attributes into dynamic libraries and executables by default. The functionality is still preserved, but it must now be manually enabled via a `-C rpath` flag. This involved a few changes to the local build system: * --disable-rpath is now the default configure option * Makefiles now prefer our own LD_LIBRARY_PATH over the user's LD_LIBRARY_PATH in order to support building rust with rust already installed. * The compiletest program was taught to correctly pass through the aux dir as a component of LD_LIBRARY_PATH in more situations. The major impact of this change is that neither rustdoc nor rustc will work out-of-the-box in all situations because they are dynamically linked. It must be arranged to ensure that the libraries of a rust installation are part of the LD_LIBRARY_PATH. The default installation paths for all platforms ensure this, but if an installation is in a nonstandard location, then configuration may be necessary. Additionally, for all developers of rustc, it will no longer be possible to run $target/stageN/bin/rustc out-of-the-box. The old behavior can be regained through the `--enable-rpath` option to the configure script. This change brings linux/mac installations in line with windows installations where rpath is not possible. Closes #11747 [breaking-change]
-
由 Alex Crichton 提交于
This involved a few changes to the local build system: * Makefiles now prefer our own LD_LIBRARY_PATH over the user's LD_LIBRARY_PATH in order to support building rust with rust already installed. * The compiletest program was taught to correctly pass through the aux dir as a component of LD_LIBRARY_PATH in more situations. This change was spliced out of #14832 to consist of just the fixes to running tests without an rpath setting embedded in executables.
-
- 19 5月, 2014 1 次提交
-
-
由 Felix S. Klock II 提交于
Two line summary: Distinguish HOST_RPATH and TARGET_RPATH; added RPATH_LINK_SEARCH; skip tests broken in stage1; general cleanup. `HOST_RPATH_VAR$(1)_T_$(2)_H_$(3)` and `TARGET_RPATH_VAR$(1)_T_$(2)_H_$(3)` both match the format of the old `RPATH_VAR$(1)_T_$(2)_H_$(3)` (which is still being set the same way that it was before, to one of either HOST/TARGET depending on what stage we are building). Namely, the format is <XXX>_RPATH_VAR = "<LD_LIB_PATH_ENVVAR>=<COLON_SEP_PATH_ENTRIES>" What this commit does: * Pass both of the (newly introduced) HOST and TARGET rpath setup vars to `maketest.py` * Update `maketest.py` to no longer update the LD_LIBRARY_PATH itself Instead, it passes along the HOST and TARGET rpath setup vars in environment variables `HOST_RPATH_ENV` and `TARGET_RPATH_ENV` * Also, pass the current stage number to maketest.py; it in turn passes it (via an env var) to run-make tests. This allows the run-make tests to selectively change behavior (e.g. turn themselves off) to deal with incompatibilities with e.g. stage1. * Cleanup: Distinguish in tools.mk between the command to run (`RUN`) and the file to generate to drive that command (`RUN_BINFILE`). The main thing this enables is that `RUN` can now setup the `TARGET_RPATH_ENV` without having to dirty up the runner code in each of the `run-make` Makefiles. * Cleanup: Factored out commands to delete dylib/rlib into REMOVE_DYLIBS/REMOVE_RLIBS. There were places where we were only calling `rm $(call DYLIB,foo)` even though we really needed to get rid of the whole glob (at least based on alex's findings on #13753 that removing the symlink does not suffice). Therefore rather than peppering the code with the awkward `rm $(TMPDIR)/$(call DYLIB_GLOB,foo)`, I instead introduced a common `REMOVE_DYLIBS` user function that expands into that when called. After I adding an analogous `REMOVE_RLIBS`, I changed all of the existing calls that rm dylibs or rlibs to use these routines instead. Note that the latter is not a true refactoring since I may have changed cases where it was our intent to only remove the sym-link. (But if that is the case, then we need to more deeply investigate alex's findings on #13753 where the system was still dynamically loading up the non-symlinked libraries that it finds on the load path.) * Added RPATH_LINK_SEARCH command and use it on Linux. On some platforms, namely Linux, when you have libboot.so that has its internal rpath set (to e.g. $(ORIGIN)/path/to/HOSTDIR), the linker still complains when you do the link step and it does not know where to find libraries that libboot.so depends upon that live in HOSTDIR (think e.g. librustuv.so). As far as I can tell, the GNU linker will consult the LD_LIBRARY_PATH as part of the linking process to find such libraries. But if you want to be more careful and not override LD_LIBRARY_PATH for the `gcc` invocation, then you need some other way to tell the linker where it can find the libraries that libboot.so needs. The solution to this on Linux is the `-Wl,-rpath-link` command line option. However, this command line option does not exist on Mac OS X, (which appears to be figuring out how to resolve the libboot.dylib dependency by some other means, perhaps by consulting the rpath setting within libboot.dylib). So, in order to abstract over this distinction, I added the RPATH_LINK_SEARCH macro to the run-make infrastructure and added calls to it where necessary to get Linux working. On architectures other than Linux, the macro expands to nothing. * Disable miscellaneous tests atop stage1. * An especially interesting instance of the previous bullet point: Excuse regex from doing rustdoc tests atop stage1. This was a (nearly-) final step to get `make check-stage1` working again. The use of a special-case check for regex here is ugly but is analogous other similar checks for regex such as the one that landed in PR #13844. The way this is written, the user will get a reminder that doc-crate-regex is being skipped whenever their rules attempt to do the crate documentation tests. This is deliberate: I want people running `make check-stage1` to be reminded about which cases are being skipped. (But if such echo noise is considered offensive, it can obviously be removed.) * Got windows working with the above changes. This portion of the commit is a cleanup revision of the (previously mentioned on try builds) re-architecting of how the LD_LIBRARY_PATH setup and extension is handled in order to accommodate Windows' (1.) use of `$PATH` for that purpose and (2.) use of spaces in `$PATH` entries (problematic for make and for interoperation with tools at the shell). * In addition, since the code has been rearchitected to pass the HOST_RPATH_DIR/TARGET_RPATH_DIR rather than a whole sh environment-variable setting command, there is no need to for the convert_path_spec calls in maketest.py, which in fact were put in place to placate Windows but were now causing the Windows builds to fail. Instead we just convert the paths to absolute paths just like all of the other path arguments. Also, note for makefile hackers: apparently you cannot quote operands to `ifeq` in Makefile (or at least, you need to be careful about adding them, e.g. to only one side).
-
- 13 5月, 2014 1 次提交
-
-
由 Brian Anderson 提交于
-
- 25 4月, 2014 1 次提交
-
-
由 Andrew Gallant 提交于
-
- 12 4月, 2014 1 次提交
-
-
由 Alex Crichton 提交于
After removing absolute rpaths, cross compile builds (notably the nightly builders) broke. This is because the RPATH was pointing at an empty directory because only the rustc binary is copied over, not all of the target libraries. This modifies the cross compile logic to fixup the rpath of the stage0 cross-compiled rustc to point to where it came from.
-
- 11 4月, 2014 1 次提交
-
-
由 Alex Crichton 提交于
Concerns have been raised about using absolute rpaths in #11746, and this is the first step towards not relying on rpaths at all. The only current use case for an absolute rpath is when a non-installed rust builds an executable that then moves from is built location. The relative rpath back to libstd and absolute rpath to the installation directory still remain (CFG_PREFIX). Closes #11746 Rebasing of #12754
-
- 04 4月, 2014 1 次提交
-
-
由 Brian Anderson 提交于
This also changes some of the download links in the documentation to 'nightly'.
-