OSX often has a more recent version of clang than it does for GCC. When an older
version of gcc is detected on OSX, the --enable-clang flag is implicitly
enabled.
When clang is enabled, also pass through --enable-libcpp to LLVM's configure
command line to help it pick up the most recent c++ runtime library. This also
changes the mklldeps.py script to pick up on whether LLVM was linked against
stdc++ or c++ based on the --cxxflags that llvm-config prints.
In an ongoing attempt to update LLVM, the bots need to update their C compilers
to something that supports c++11 (LLVM recently switched). The OSX bots are
running Lion (10.7), which only supports up to gcc 4.2 and clang 3.2. Apparently
the libstdc++ is too old (even on the most updated command line tools) for LLVM,
but using libc++ instead appears to work just fine.
This comes with a number of fixes to be compatible with upstream LLVM:
* Previously all monomorphizations of "mem::size_of()" would receive the same
symbol. In the past LLVM would silently rename duplicated symbols, but it
appears to now be dropping the duplicate symbols and functions now. The symbol
names of monomorphized functions are now no longer solely based on the type of
the function, but rather the type and the unique hash for the
monomorphization.
* Split stacks are no longer a global feature controlled by a flag in LLVM.
Instead, they are opt-in on a per-function basis through a function attribute.
The rust #[no_split_stack] attribute will disable this, otherwise all
functions have #[split_stack] attached to them.
* The compare and swap instruction now takes two atomic orderings, one for the
successful case and one for the failure case. LLVM internally has an
implementation of calculating the appropriate failure ordering given a
particular success ordering (previously only a success ordering was
specified), and I copied that into the intrinsic translation so the failure
ordering isn't supplied on a source level for now.
* Minor tweaks to LLVM's API in terms of debuginfo, naming, c++11 conventions,
etc.
The previous regex was a bit to strict, rejecting versions such as 3.4.1 which
is apparently the version which travis is currently installing, causing all
travis builds to fail.
MSYS2 supports `MINGW64` system for 64-bit environment. It sets
`MSYSTEM=MINGW64` environment variable, which changes output of
`uname -s` thus affects `configure` behavior.
This patch adds `MINGW64*` support for `configure`.
- remove `node.js` dep., it has no effect as of #12747 (1)
- switch between LaTeX compilers, some cleanups
- CSS: fixup the print stylesheet, refactor highlighting code (2)
(1): `prep.js` outputs its own HTML directives, which `pandoc` cannot recognize when converting the document into LaTeX (this is why the PDF docs have never been highlighted as of now).
Note that if we were to add the `.rust` class to snippets, we could probably use pandoc's native highlighting capatibilities i.e. Kate ([here is](http://adrientetar.github.io/rust-tuts/tutorial/tutorial.pdf) an example of that).
(2): the only real highlighting change is for lifetimes which are now brown instead of red, the rest is just refactor of twos shades of red that look the same.
Also I made numbers highlighting for src in rustdoc a tint more clear so that it is less bothering.
@alexcrichton, @huonw
Closes#9873. Closes#12788.
`prep.js` outputs its own HTML directives, which `pandoc` cannot
recognize when converting the document into LaTeX (this is why the
PDF docs have never been highlighted as of now).
Note that if we were to add the `.rust` class to snippets, we could
probably use pandoc's native highlighting capatibilities i.e. Kate.
By default, the compiler and libraries are all still built with rpaths, but this
can be opted out of with --disable-rpath to ./configure or --no-rpath to rustc.
cc #5219
This reorganizes the documentation index to be more focused on the in-tree docs, and to clean up the style, and it also adds @steveklabnik's pointer guide.
Ensure configure creates doc/guides directory
Fix configure makefile and tests
Remove old guides dir and configure option, convert testing to guide
Remove ignored files
Fix submodule issue
prepend dir in makefile so that bor knows how to build the docs
S to uppercase
llvm supports both win32 native threads and pthread,
but configure tries to find pthread first.
This manually disables pthread to use native api.
This removes libpthreads-2.dll dependency on librustc.
Apple replaced gcc with clang, but kept around a stub gcc to call
clang. This adds a check in `configure` to detect when gcc is
really clang, and switch to using clang in this situation.
Closes#10811.
CFG_BUILD_DIR, CFG_LLVM_SRC_DIR and CFG_SRC_DIR all have trailing
slashes, by definition, so this is correct.
(This is purely cosmetic; the doubled slash is ignored by all the tools we're using.)
This commit implements the support necessary for generating both intermediate
and result static rust libraries. This is an implementation of my thoughts in
https://mail.mozilla.org/pipermail/rust-dev/2013-November/006686.html.
When compiling a library, we still retain the "lib" option, although now there
are "rlib", "staticlib", and "dylib" as options for crate_type (and these are
stackable). The idea of "lib" is to generate the "compiler default" instead of
having too choose (although all are interchangeable). For now I have left the
"complier default" to be a dynamic library for size reasons.
Of the rust libraries, lib{std,extra,rustuv} will bootstrap with an
rlib/dylib pair, but lib{rustc,syntax,rustdoc,rustpkg} will only be built as a
dynamic object. I chose this for size reasons, but also because you're probably
not going to be embedding the rustc compiler anywhere any time soon.
Other than the options outlined above, there are a few defaults/preferences that
are now opinionated in the compiler:
* If both a .dylib and .rlib are found for a rust library, the compiler will
prefer the .rlib variant. This is overridable via the -Z prefer-dynamic option
* If generating a "lib", the compiler will generate a dynamic library. This is
overridable by explicitly saying what flavor you'd like (rlib, staticlib,
dylib).
* If no options are passed to the command line, and no crate_type is found in
the destination crate, then an executable is generated
With this change, you can successfully build a rust program with 0 dynamic
dependencies on rust libraries. There is still a dynamic dependency on
librustrt, but I plan on removing that in a subsequent commit.
This change includes no tests just yet. Our current testing
infrastructure/harnesses aren't very amenable to doing flavorful things with
linking, so I'm planning on adding a new mode of testing which I believe belongs
as a separate commit.
Closes#552
Earlier versions of pandoc don't have the `default.html5` template file. When `make docs` is run, the build process fails with this message.
pandoc: doc/rust.html
pandoc: /usr/share/pandoc-1.8.2.1/templates/default.html5: openFile: does not exist (No such file or directory)
node.js:201
throw e; // process.nextTick error, or 'error' event on first tick
^
Error: write EPIPE
at errnoException (net.js:670:11)
at Object.afterWrite [as oncomplete] (net.js:503:19)
make: *** [doc/rust.html] Error 1
Previously we were actually overwriting `CFG_{HOST,TARGET,BUILD}` with `CFG_{HOST,TARGET,BUILD}_TRIPLE(S)` since configure tested for the legacy one by checking if it was empty which would never be the case. That meant it wouldn't split up multiple triples and just treat it as one long triple.
This pull also fixes the rules that were changed when librustuv was added to use the right CFG_ vars and removes the legacy flags.
As discovered in #9925, it turns out that we weren't using jemalloc on most
platforms. Additionally, on some platforms we were using it incorrectly and
mismatching the libc version of malloc with the jemalloc version of malloc.
Additionally, it's not clear that using jemalloc is indeed a large performance
win in particular situtations. This could be due to building jemalloc
incorrectly, or possibly due to using jemalloc incorrectly, but it is unclear at
this time.
Until jemalloc can be confirmed to integrate correctly on all platforms and has
verifiable large performance wins on platforms as well, it shouldn't be part of
the default build process. It should still be available for use via the
LD_PRELOAD trick on various architectures, but using it as the default allocator
for everything would require guaranteeing that it works in all situtations,
which it currently doesn't.
Closes#9925
Many people will be very confused that their debug! statements aren't working
when they first use rust only to learn that they should have been building with
`--cfg debug` the entire time. This inverts the meaning of the flag to instead
of enabling debug statements, now it disables debug statements.
This way the default behavior is a bit more reasonable, and requires less
end-user configuration. Furthermore, this turns on debug by default when
building the rustc compiler.
Builds are considerably faster without assertions, so when working on
e.g. libstd, which doesn't directly interact with LLVM, one might want
to disable them.
Closes#3816.
Without --quiet, git shows its own progress report of download. It's not really a progress bar, but it's a percentage and files incoming. This will help initial downloads of LLVM to not cause people to wonder why their configure script is hanging for hours.
r? @graydon
When no arguments are given, echo prints a blank line. These two are
equivalent:
$ echo ""
$ echo
Replace the former by the latter.
Signed-off-by: Ramkumar Ramachandra <artagnon@gmail.com>
Fix#6805: add --enable-ccache configure option to prefix compiler invocations with `ccache` to attempt to reuse common results, e.g. for LLVM (re)builds.
The information at developer [Note-ccache](../../wiki/Note-ccache) and at [ccache and clang concerns](http://petereisentraut.blogspot.fr/2011/09/ccache-and-clang-part-2.html) were what drove my introduction of the `-Qunused-arguments` and `CCACHE_CPP2` options. (Though I did confirm first-hand that at least the first really is necessary.)
Yes, one certainly can re-route how `gcc` and `clang` are resolved in one's PATH and use that as a way to invoke `ccache`. But I personally do not want to introduce that change to my own PATH, and this seems like a small enough change that it does not hurt to add it, at least for now. (I don't know what form it would take when we move over to `rustpkg`.)
Apple Clang uses different version numbering than "regular" clang, but
it also provides the "regular" version it's based on. Update the sed
pattern to pull out this "regular" version number instead of the Apple
version number.
This lets us use #ifdefs to determine which stage of the build we happen
to be in, which is useful in the event we need to make changes to rustrt
that are incompatible with the code generated by stage0.
This should help pave the way to completing #6575, which will likely
require changes to type signatures for spawn_fn & glue_fn in rustrt.
* They didn't work before, because the location of the tests caused the
'sysroot' option to crate lookup to be wrong for finding the correct stage's
core/std libraries. This moves the compiled tests from the $host/test
directory into a $host/$stage/test directory. This means that the sysroot will
be correct and the core/std libraries can actually be found
* The LLVM bindings apparently aren't threadsafe, so we can't run multiple tests
in parallel.
Removing it from the tree is an ordeal and there is no official way
to disable clang via LLVM's Makefiles so this edits the Makefile
in llvm/tools after running configure.
Previously the build system only checked for llvm-3.1 - 2.8.
Now also 3.2 and 3.2svn is accepted.
Signed-off-by: Fabian Deutsch <fabian.deutsch@gmx.de>
Previously the build system only checked for llvm-3.1 - 2.8.
Now also 3.2 and 3.2svn is accepted.
Signed-off-by: Fabian Deutsch <fabian.deutsch@gmx.de>
In order to mitigate typo of target-triples, error notification of unsupported target triples which defined in mk/platform.mk added.
minor fix for arm-linux-androideabi added.
- thanks to work in libuv's upstream, we can call libuv's Makefile directly
with parameters, instead of descending in gyp-uv madness and generating
our own.
Ubuntu's clang packages have additional information appended to the end of
the version.
- Building Rust v0.5 with clang v3.0-6ubuntu3 fails.
- Building Rust v0.5 and incoming with clang v3.1-5ppa (backported from Debian)
works.
Closes#4441.
This addresses issue #2720. According to LLVM's documentation, it requires a
version of Python between 2.4 and 2.7. Without the proper version, LLVM fails
to build with cryptic errors. Prior to this commit, the configure script
checked for the `python` command in the environment, but didn't actually check
the version, which can cause problems e.g. on Linux distros where the default
is Python 3. Now the configure script always prefers to select a more specific
version of Python when available, in the order `python2.7` > `python2.6` >
`python2` > `python`, and will always check to ensure that the interpreter's
version is in the correct range.
rather than the snapshots.
make sure to get all of the files.
update to add nmatsakis' requested feature of pointing to a
different rustc install root.
usage: --enable-local-rust to enable
--local-rust-root="/path/to/rustc/" to change the path, which defaults to
"/usr/local/"
Tested on OS X and Linux, likely broken on windows.
When CFG_ENABLE_DEBUG is defined it will call rustc with -g --cfg=debug
and cc with -DRUST_DEBUG. Otherwise it calls rustc with --cfg=ndebug and cc
with -DRUST_NDEBUG.
I plan to use this for a few things in the runtime.
Linux perf tool version 3.2 introduced a new option "--log-fd" defaults
to 0, which leads to error "Failed opening logfd: Illegal argument" when
executing perf tests.
Set logfd to stderr to let perf test work.
Issue #1538
Naturaldocs isn't really that great but it seems easier to get
something working than with doxygen, for which we would need to
convert rust code to something C++ish. We probably want to just
write a rustdoc utility at some point.
On my machine I have two LLVM builds, one of regular HEAD and one
for Rust in ~/rust-llvm - by default CFG_LLVM_CONFIG is set to
/usr/local/bin/llvm-config which is wrong, because the probe for it
initially happens earlier in configure and succeeds (so putvar is called.)
This causes it to be emitted twice into the Makefile but the second
instance wins.
