On Fri, Nov 15, 2013 at 12:28 PM, Alex Crichton <[email protected]> wrote: >>> Primarily, I believe that if desired, rustc should be able to generate an >>> executable or dynamic library with no dependence on any rust libraries. This >>> includes things like librustrt and libextra. Rust shouldn't be striving to >>> lift >>> dependence on system libraries, that'll come at later times if need be. >> >> It seems like you *are* striving to lift dependencies on non-rust >> libraries, though. For example, you mention having libuv be statically >> imported into a .rlib file etc. Or did I misunderstand? > > Hm, I suppose I should re-phrase. Rust's linkage model should not > attempt to lift dependence on global native libraries. These global > libraries (like libm and librt on linux) should be assumed to be > everywhere. Our result artifacts must always be linked against them > (if their functionality is used). On the other hand, any build > artifacts that are a result of a local build process should not be > considered downstream dependencies as well. To this end, I mainly > point out that rust should roll in local native static libraries, and > just live with global native dynamic libraries.
This can't be assumed if we want to support freestanding use. Removing the need for rust-core means support for environments without features like floating point and amenities provided by a kernel to user-land processes. Perhaps I'm misunderstanding what you mean here. _______________________________________________ Rust-dev mailing list [email protected] https://mail.mozilla.org/listinfo/rust-dev
