-
Notifications
You must be signed in to change notification settings - Fork 13.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
trans: Be a little more picky about dllimport #27208
Conversation
Currently you can hit a link error on MSVC by only referencing static items from a crate (no functions for example) and then link to the crate statically (as all Rust crates do 99% of the time). A detailed investigation can be found [on github][details], but the tl;dr is that we need to stop applying dllimport so aggressively. This commit alters the application of dllimport on constants to only cases where the crate the constant originated from will be linked as a dylib in some output crate type. That way if we're just linking rlibs (like the motivation for this issue) we won't use dllimport. For the compiler, however, (which has lots of dylibs) we'll use dllimport. [details]: rust-lang#26591 (comment) cc rust-lang#26591
r? @Aatch (rust_highfive has picked a reviewer for you, use r? to override) |
r? @brson |
@bors r+ I approved this as a workaround, but it seems like the dllimport situation is a big mess, and from your code comment maybe impossible to resolve correctly with the type of hueristic-based approach we've got now. |
📌 Commit a0efd3a has been approved by |
⌛ Testing commit a0efd3a with merge a24dec0... |
💔 Test failed - auto-win-gnu-64-nopt-t |
@bors: retry On Thu, Jul 23, 2015 at 4:36 PM, bors [email protected] wrote:
|
Currently you can hit a link error on MSVC by only referencing static items from a crate (no functions for example) and then link to the crate statically (as all Rust crates do 99% of the time). A detailed investigation can be found [on github][details], but the tl;dr is that we need to stop applying dllimport so aggressively. This commit alters the application of dllimport on constants to only cases where the crate the constant originated from will be linked as a dylib in some output crate type. That way if we're just linking rlibs (like the motivation for this issue) we won't use dllimport. For the compiler, however, (which has lots of dylibs) we'll use dllimport. [details]: #26591 (comment) cc #26591
Currently you can hit a link error on MSVC by only referencing static items from
a crate (no functions for example) and then link to the crate statically (as all
Rust crates do 99% of the time). A detailed investigation can be found on
github, but the tl;dr is that we need to stop applying dllimport so
aggressively.
This commit alters the application of dllimport on constants to only cases where
the crate the constant originated from will be linked as a dylib in some output
crate type. That way if we're just linking rlibs (like the motivation for this
issue) we won't use dllimport. For the compiler, however, (which has lots of
dylibs) we'll use dllimport.
cc #26591