]> git.lizzy.rs Git - rust.git/commit
auto merge of #10422 : alexcrichton/rust/explicit-crate-map, r=pcwalton
authorbors <bors@rust-lang.org>
Tue, 12 Nov 2013 00:11:22 +0000 (16:11 -0800)
committerbors <bors@rust-lang.org>
Tue, 12 Nov 2013 00:11:22 +0000 (16:11 -0800)
commitc0b7972f7d63e4b55098797cb48949b00d3ffee7
treed73361e59d704339a9dd2f2e68d23da09b5a00de
parent88e383ef1e702666159bdc899d81e30927479501
parent2eb92b77a97b5657919d636700d72f7578af2a4f
auto merge of #10422 : alexcrichton/rust/explicit-crate-map, r=pcwalton

As we start to move runtime components into the crate map, it's becoming harder
and harder to start the runtime from a C function as rust is embedded in another
application. Right now if you compile a rust crate as a dynamic library which is
then linked to another application, when using std::rt::start there are no I/O
local services, even though rustuv was linked against and requested. The reason
for this is that there is no top level crate map available specifying where to
find libuv I/O.

This option is not meant to be used regularly, but rather whenever compiling a
final library crate and linking it into another application. This lifts the
requirement that to get a crate map you must have the final destination be an
executable.
src/librustc/middle/trans/base.rs