https://github.com/rust-lang/rust http://git.dreamy.place/mirrors/rust/atom?h=0.10 2014-03-25T16:47:22+00:00 2014-03-25T16:47:22+00:00 Alex Crichton alex@alexcrichton.com 2014-03-25T16:47:22+00:00 urn:sha1:d1f8fb26f5dc52556153c817fbe03dae5f4295b7 Apparently we had forgotten to do this for freebsd, causing possible problems on FreeBSD 10. The discussion in #12324 has some more details about how it's missing. 2014-02-14T16:07:46+00:00 Alex Crichton alex@alexcrichton.com 2014-02-04T16:37:07+00:00 urn:sha1:28fa81a954a5722eedc838f413eb7b8ed04a8e95 This will hopefully bring us closer to #11937. We're still using gcc's idea of "startup files", but this should prevent us from leaking in dependencies that we don't quite want (libgcc for example once compiler-rt is what we use). 2013-12-30T22:35:55+00:00 Alex Crichton alex@alexcrichton.com 2013-12-30T04:09:40+00:00 urn:sha1:726091fea5ab7663c6e7c7cfdde015afc0065e46 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-26T19:30:23+00:00 Alex Crichton alex@alexcrichton.com 2013-12-26T06:20:43+00:00 urn:sha1:ab431a20c0fe3f00f3d124200d10e13877dcf20b 2013-12-24T20:13:42+00:00 Vadim Chugunov vadimcn@gmail.com 2013-12-16T01:17:07+00:00 urn:sha1:e3b37154b0f321ad74f293d98d9be2ae512c2ec7 2013-12-13T07:06:59+00:00 Fabrice Desré fabrice@desre.org 2013-12-13T07:06:59+00:00 urn:sha1:57c62816492d83d1c404c10bb9c5f0e28c60c086 2013-12-03T22:31:54+00:00 Alex Crichton alex@alexcrichton.com 2013-12-01T00:38:07+00:00 urn:sha1:acc5e32e53d313a890a07cb0b693ce8df5bc94ce 2013-11-30T02:36:14+00:00 Alex Crichton alex@alexcrichton.com 2013-11-16T10:02:07+00:00 urn:sha1:9fbba7b2eeabd073f9518f2dbd50f4eabb621c67 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-30T02:36:13+00:00 Alex Crichton alex@alexcrichton.com 2013-11-15T22:03:29+00:00 urn:sha1:e338a4154b134fc1d4628496d4ccf85b7af7c443 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