On Fri, Nov 15, 2013 at 09:28:49AM -0800, Alex Crichton wrote: > To this end, I mainly > point out that rust should roll in local native static libraries, and > just live with global native dynamic libraries.
How does rustc know the difference? Because the "local native" libraries are tagged as #[link(once)]? (nit: maybe link(static) would be clearer?) > 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. Is this just a matter of changing what is hashed when we construct the symbol name (or dropping the symbol hashes entirely)? That doesn't seem very far. Are there are a lot of other things standing in the way that immediately come to mind? Can we try and document what those issues are? Things that I can think of off the top of my head: - Static constants: what things are compiled in to foreign crates? - Enum discriminants: do we want to provide a (slow) way for crates to match against enum variants without inlining the discriminat value associated with each variant? - Inline and generic functions: currently, we export the bodies of fns that are marked #[inline] or which are public and generic. Clearly if one is concerned about binary compatibility, these functions are the most subtle ones to reason about, since a downstream consumer will continue to use the old version *even if* they link against your new library. It might make sense to have a rule that, in a dynamic linking scenario, no function body is exported that is not explicitly annotated for export. This implies that we have a way to "pre-instantiate" generic functions (like C++ does) and probably that we have an annotation that means "export this IR so it can be instantiated" but which does not provide an LLVM inline hint, since that might not be appropriate. > Does that make sense? This is a fairly major decision, and I want to > make sure that everyone's on board with it. Regardless of whether or not we are able to present a clear ABI compatibility story (and I agree we do not right now), it's always going to be a fairly complicated set of requirements that library authors will have to reason about. We can make rules that guarantee binary compatibility, but that does not imply semantic compatibility. The sense of a boolean parameter might change, for example, or the set of flags might change. Therefore, I can see an argument that says one ought to "opt in" to dynamic linking. OTOH, it's more the producer that has to be careful about using semantic versioning and so on, not so much the consumer, so I'm not sure whether that argument really makes sense. Niko _______________________________________________ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
