rust - https://github.com/rust-lang/rust

Age	Commit message (Collapse)	Author	Lines
2013-12-30	Convert some C functions to rust functions	Alex Crichton	-2/+0
	Right now on linux, an empty executable with LTO still depends on librt becaues of the clock_gettime function in rust_builtin.o, but this commit moves this dependency into a rust function which is subject to elimination via LTO. At the same time, this also drops libstd's dependency on librt on unices that are not OSX because the library is only used by extra::time (and now the dependency is listed in that module instead).
2013-12-26	Register new snapshots	Alex Crichton	-25/+0

2013-12-24	Stop using C++ exceptions for stack unwinding.	Vadim Chugunov	-4/+25

2013-12-12	Remove dependency on gnustl_shared for android builds	Fabrice Desré	-1/+0

2013-12-03	Register new snapshots	Alex Crichton	-5/+1

2013-11-29	Statically link librustrt to libstd	Alex Crichton	-1/+7
	This commit alters the build process of the compiler to build a static librustrt.a instead of a dynamic version. This means that we can stop distributing librustrt as well as default linking against it in the compiler. This also means that if you attempt to build rust code without libstd, it will no longer work if there are any landing pads in play. The reason for this is that LLVM and rustc will emit calls to the various upcalls in librustrt used to manage exception handling. In theory we could split librustrt into librustrt and librustupcall. We would then distribute librustupcall and link to it for all programs using landing pads, but I would rather see just one librustrt artifact and simplify the build process. The major benefit of doing this is that building a static rust library for use in embedded situations all of a sudden just became a whole lot more feasible. Closes #3361
2013-11-29	Add generation of static libraries to rustc	Alex Crichton	-0/+48
	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