-
Notifications
You must be signed in to change notification settings - Fork 12.9k
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
Implement raw-dylib support for windows-gnu #90782
Conversation
(rust-highfive has picked a reviewer for you, use r? to override) |
@petrochenkov this may interest you |
This comment has been minimized.
This comment has been minimized.
One nit in a comment, and also I do think we need better handling for errors writing files. But otherwise this looks good to me. |
@joshtriplett, did you review this closely enough to approve it? If not, I'll take a closer look tomorrow. |
General note: I have seen @joshtriplett 's requests for modifications, and I'll look into those. It may be a while before I can get to that, unfortunately, as an unrelated high-priority project has come up at work that is consuming all my bandwidth at the moment. I have no intention of abandoning this PR, but I'm not sure how quickly I'll be able to respond. |
@rustbot label -S-waiting-on-author +S-waiting-on-review |
cc @nagisa who left some unresolved comments in the original PR. |
@michaelwoerister Closely enough to post a comment and feedback, but not closely enough to r+ it myself. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for the PR, @ricobbe! This looks great. I appreciate the solid tests.
I left a few comments below.
This comment has been minimized.
This comment has been minimized.
@rustbot label -S-waiting-on-author +S-waiting-on-review |
I went ahead and marked this "waiting on review" even though there's an unresolved comment; I'd like to hear feedback on my response before starting to work on that particular point. |
@michaelwoerister , @mati865 I'd particularly like to hear your feedback on the question I raised in a comment in rustc_codegen_llvm/src/back/archive.rs, line 453 |
Are there any other outstanding concerns with this PR? We'd really like to get it merged soon, if that's at all possible. |
Looks good to me now. I think it's better to merge it and then do the rustup testing. Trying to coax CI to produce the right binaries before merging seems like an unnecessary complication since this is all still behind a feature flag anyway. @ricobbe, would you mind squashing the commits? The history has become a bit too messy to merge as is. |
I still doubt this will work without external mingw-w64 based toolchain in PATH but given the fact this is nightly feature I agree there is no need to block this PR. |
4bb9086
to
0cf7fd1
Compare
@bors r+ |
📌 Commit 0cf7fd1 has been approved by |
…woerister Implement raw-dylib support for windows-gnu Add support for `#[link(kind = "raw-dylib")]` on windows-gnu targets. Work around binutils's linker's inability to read import libraries produced by LLVM by calling out to the binutils `dlltool` utility to create an import library from a temporary .DEF file; this approach is effectively a slightly refined version of `@mati865's` earlier attempt at this strategy in PR rust-lang#88801. (In particular, this attempt at this strategy adds support for `#[link_ordinal(...)]` as well.) In support of rust-lang#58713.
…woerister Implement raw-dylib support for windows-gnu Add support for `#[link(kind = "raw-dylib")]` on windows-gnu targets. Work around binutils's linker's inability to read import libraries produced by LLVM by calling out to the binutils `dlltool` utility to create an import library from a temporary .DEF file; this approach is effectively a slightly refined version of ``@mati865's`` earlier attempt at this strategy in PR rust-lang#88801. (In particular, this attempt at this strategy adds support for `#[link_ordinal(...)]` as well.) In support of rust-lang#58713.
…woerister Implement raw-dylib support for windows-gnu Add support for `#[link(kind = "raw-dylib")]` on windows-gnu targets. Work around binutils's linker's inability to read import libraries produced by LLVM by calling out to the binutils `dlltool` utility to create an import library from a temporary .DEF file; this approach is effectively a slightly refined version of ```@mati865's``` earlier attempt at this strategy in PR rust-lang#88801. (In particular, this attempt at this strategy adds support for `#[link_ordinal(...)]` as well.) In support of rust-lang#58713.
Just checking to make sure I understand the state of this PR: it's been approved, but there have been troubles getting a clean roll-up PR. Is that correct? Also, just to confirm: no action is needed on my part at the moment, right? |
Correct, you can see it's position in the queue over https://bors.rust-lang.org/queue/rust |
Sounds good. Thanks for the confirmation! |
…askrgr Rollup of 9 pull requests Successful merges: - rust-lang#90782 (Implement raw-dylib support for windows-gnu) - rust-lang#91150 (Let qpath contain NtTy: `<$:ty as $:ty>::…`) - rust-lang#92425 (Improve SIMD casts) - rust-lang#92692 (Simplify and unify rustdoc sidebar styles) - rust-lang#92780 (Directly use ConstValue for single literals in blocks) - rust-lang#92924 (Delete pretty printer tracing) - rust-lang#93018 (Remove some unused `Ord` derives based on `Span`) - rust-lang#93026 (fix typo in `max` description for f32/f64) - rust-lang#93035 (Fix stdarch submodule pointing to commit outside tree) Failed merges: - rust-lang#92861 (Rustdoc mobile: put out-of-band info on its own line) r? `@ghost` `@rustbot` modify labels: rollup
…dylib, r=michaelwoerister Fix MinGW target detection in raw-dylib LLVM target doesn't have to be the same as Rust target so relying on it is wrong. It was one of concerns in rust-lang#88801 that was not fixed in rust-lang#90782.
Add support for
#[link(kind = "raw-dylib")]
on windows-gnu targets. Work around binutils's linker's inability to read import libraries produced by LLVM by calling out to the binutilsdlltool
utility to create an import library from a temporary .DEF file; this approach is effectively a slightly refined version of @mati865's earlier attempt at this strategy in PR #88801. (In particular, this attempt at this strategy adds support for#[link_ordinal(...)]
as well.)In support of #58713.