>> 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. > Does this imply that all Rust programs will be executed with whatever > specific version of libsundown and libuv was produced as part of the > Rust compiler build process? (I'm not implying this is a bad thing, > necessarily, just trying to understand) Correct. We as distributors of the rust compile could choose to make libsundown a dynamic library which is then distributed and upgradeable. We may also choose to link it statically to show that it cannot be in-place upgraded. >> I would propose that the compiler automatically favors static >> linkage over dynamic linkage due to various rust ABI issues. > > Could you elaborate? What issues are you thinking of? I should rephrase. I'm not an ABI expert, and my concerns actually aren't really that related to ABI (although I know that many others do have concerns about this). My primary concern is the current fragility of a symbol in rust. If I add a doc-comment in libstd, I will likely change many symbols in the output dynamic library. This is another problem entirely, but it has repercussions for this right now. In favoring dynamic libraries, rust is stating that it is available for an in-place upgrade. The rust compiler is currently sufficiently far from this goal that I do not believe that we should be favoring dynamic linking. By favoring static linking instead, we are lifting ourselves from this burden. When we upgrade the rust compiler a year from now (2.0, woo!), all previous rust executables will continue to run just fine (assuming they weren't linked dynamically). Additionally, any application which has a linked version of rust will continue to work. Does that make sense? This is a fairly major decision, and I want to make sure that everyone's on board with it. > Unless I'm missing something, it seems like what we would want to do > is to have the .rlib file contain LLVM IR, at least for the Rust code > that was compiled / statically linked against. If we can, I think we > should just make LTO happen by default whenver you statically link, > rather than having it be a separate option Interesting idea! Sounds like this definitely along the right lines, and so long as we don't advertise our .rlib format it sounds like we can silently do this at any time in the future. _______________________________________________ Rust-dev mailing list [email protected] https://mail.mozilla.org/listinfo/rust-dev
