A few quick questions and comments: On Fri, Nov 15, 2013 at 12:09:28AM -0800, Alex Crichton wrote: > I've been thinking about static linking recently, along with a little bit of > linking in general, and I wanted to see what others thought. > > # The Goal > > 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? > As mentioned above, these files are similar to the compiler's .o output. The > only other component which can be considered for inclusion in this .o file is > all native static library dependencies. These are encoded as #[link(once)] in > linkage attributes. The reason for doing this is that it's likely to be common > to have a local static library which is not available in distribution, but is > always available for the build process. Examples for the compiler include > libsundown, libuv, libuv_support, and maybe librustrt. 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) > 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? > This default could be switched in the future, but it simply means > that if the compiler finds a .so and a .rlib, it will suck in the > .rlib before sucking in the .so. What does "suck in" here mean? I don't think this is as simple as what file the compiler opens, but rather it means that by default you'd get static linking and hence wouldn't require the .so to be distributed but also couldn't support independent library version upgrades, right? > What are others' thoughts on this? Is this too complex of a system? Is there a > glaring omission of use cases? I think it generally makes sense and doesn't seem overly complicated, though I'm not sure if there are missing use cases or not. > As a side node, after writing all this up, I remembered LTO as an > option for generating libraries. I don't think I know enough about LTO > to be able to say whether it would fit in this system or not, but my > basic understanding is that an LTO library is just "IR in a box". We > could add a --lto output option which has pretty much the same > semantics as the --rlib option, but with a different format. Again > though, I haven't thought how native libraries would fit into that > scenario, but I believe that we could fairly easily accommodate LTO in > a system like this. 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, but it is fine if that doesn't work yet in the first version (e.g., because .rlib is just a .o file). Still I agree that your scheme accommodates it just fine. Niko _______________________________________________ Rust-dev mailing list [email protected] https://mail.mozilla.org/listinfo/rust-dev
