On 11/18/2013 06:22 PM, Alex Crichton wrote:
* #[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?
It would be the same purpose as putting them on extern blocks - to tell
the linker what other libraries to link to. It would function exactly
the same. The only reason link attributes ever *need* to be specifically
on an extern block is to support OS X two-level namespaces (which I
don't know anything about and haven't actually seen).
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
