>> * #[link(...)] becomes the new method of specifying linkage semantics on >> extern >> blocks, and it may be used similarly to link_args today > > I'd kind of like for this to be available at the crate level too since most > libraries don't use OS X two-level namespaces and it's more convient to me to > just put all the linkage at the top of the crate. Of course this conflicts > with the `link` attribute of crates, which I think is poorly named anyway.
What purpose did you have in mind for the #[link] attribute at the top of the crate? Is the crate saying how it should be linked to other crates? > I don't really understand what 'once' implies in `link(once)` and how it > relates to statics. If a static library *must* be linked, then dynamic > libraries may not be linked? Why is that? If 'once' implies 'static', can we > just say 'link(static)'? I assume some argument propagation is going to come > into play here ... > > Will also need to accomodate some other common features like, e.g. > `link(framework = "foo")` or something for OS X frameworks. What this ended up turning out as is #[link(name = “foo”, kind = “static”)]. I think that a “framework” kind would fit quite well for this use case. > .rlib files also need the crate metadata. I agree > What happens when two upstream crates link to the same native static library? > In the final link step they are both going to be linked in, and I presume > there's some kind of conflict? Right now they’re both linked in. I didn’t envision this as a use case for rustc to complain about, but it would be simple enough to iterate over all upstream crates and see if the same static library were linked twice. My implementation requires metadata about the linkage regardless. > How does one opt into linking to dynamic libraries? Without some further > mechanism everybody will be linking to the static libstd. I’ve reserved another -Z flag for ‘-Z prefer-dynamic' > I took this to mean that we would just be packaging up the static libraries > to save them for the final link step (since the rlib is just a .o file, not > pre-linked to it's static lib dependencies). The effect of this though may be > that all downstream crates implicitly have access to all the static library's > symbols. This actually what currently happens. The resulting rlib file already contains all of the static native libraries bundled inside of it. This is achieved via ld’s -r option. It is true that all of the symbols leak through, however, and this is unfortunate. I’d like to explore methods of preventing this, but I only know of one way currently. We’d create a list of all symbols in the rust library (an actual file on the filesystem), and then pass that to the linker saying “here are all the exported symbols, discard everything else.” _______________________________________________ Rust-dev mailing list [email protected] https://mail.mozilla.org/listinfo/rust-dev
