linkage: Add a note about symbol visibility and unused sections to the paragraph about staticlibs #1361
Conversation
…e paragraph about staticlibs Fixes rust-lang/rust#111593
|
@bjorn3 or @petrochenkov Does the information here look correct to you? |
|
Yes, but I'm not sure this belongs to the language reference? |
| dependencies, including the standard library, and also exports all public | ||
| symbols of them, linking the static library into an executable or shared | ||
| library will need special care. In case of a shared library the list of | ||
| exported symbols will have to be limited via e.g. a linker or symbol version |
There was a problem hiding this comment.
I wouldn't say that they have to or that special care is needed.
It's more like "if you want to optimize the output in a similar way to rustc".
There was a problem hiding this comment.
In case of a shared library it seems more than an optimization as you're otherwise risking symbol conflicts, but yes.
How about softening it from the (current) "must" to "should"?
Yea, there is a gray area where it is unclear how much regarding crate types and linkage are implementation-specific, and what should be considered part of the language. We haven't really nailed down how to draw those lines (#599 discusses this a bit). I seem to recall thinking that most of this chapter should be moved to the I would love to see a section of the rustc guide (or an entire book!) on linking with Rust. This seems like the kind of content that would live there. I think for now, without a clear home for this, leaving it here would be fine. It can be moved to a better home in the future. |
|
I agree that the reference seems like the wrong place, but this specific chapter seems to be the best currently existing place for this :) |
Let's say "may" rather than "will" here.
Fixes rust-lang/rust#111593
CC @bjorn3