-
Notifications
You must be signed in to change notification settings - Fork 12.7k
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
Stabilize raw_dylib (#[link(kind = "raw-dylib")]
)
#104218
Conversation
Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @ehuss (or someone else) soon. Please see the contribution instructions for more information. |
af71c84
to
97dc3f9
Compare
Stabilization proposed in #58713 (comment). The remaining mentions of |
97dc3f9
to
e981b46
Compare
This comment has been minimized.
This comment has been minimized.
This stabilizes the raw-dylib and link_ordinal features (rust-lang#58713) for the remaining architecture: x86.
e981b46
to
ec4d15d
Compare
Thanks for the PR, @tbu-! I'll take a closer look on Monday -- I'll need some time to get up-to-speed with the current state of things. |
Thanks for the PR, @tbu-! I have some comments:
|
One more issue blocking stabilization for x86 (I'm currently looking into it): #104453 |
Cross-compilation would also block windows-rs from going beyond experimental support. #103939 |
@michaelwoerister I think there is one more problem related to the mentioned issue that maybe even should have blocked stabilization on 64-bit platforms. |
Yes, good catch @mati865! I came across that too while taking a look at #103939. As far as I can tell, the plan has always been to also stabilize the But one open question there is if |
I think |
I think that would be confusing, no? If I explicitly add |
My suggestion is to stabilize
|
OK, I have no strong opinion here. Being able to remove the entire |
☔ The latest upstream changes (presumably #105008) made this pull request unmergeable. Please resolve the merge conflicts. |
hello, checking for progress. With regard to this comment and perhaps also this comment, can the update situation be posted here? Namely if there is some more design/discussion needed or the review con move forward. I'll switch the review status to author for a feedback. @tbu- feel free to request a review with @rustbot author |
Closing this as inactive. Feel free to create a new PR if interested in continuing with this. |
Fix cross-compiling with dlltool for raw-dylib Fix for rust-lang#103939 Issue Details: When attempting to cross-compile using the `raw-dylib` feature and the GNU toolchain, rustc would attempt to find a cross-compiling version of dlltool (e.g., `i686-w64-mingw32-dlltool`). The has two issues 1) on Windows dlltool is always `dlltool` (no cross-compiling named versions exist) and 2) it only supported compiling to i686 and x86_64 resulting in ARM 32 and 64 compiling as x86_64. Fix Details: * On Windows always use the normal `dlltool` binary. * Add the ARM64 cross-compiling dlltool name (support for this is coming: https://sourceware.org/bugzilla/show_bug.cgi?id=29964) * Provide the `-m` argument to dlltool to indicate the target machine type. (This is the first of two PRs to fix the remaining issues for the `raw-dylib` feature (rust-lang#58713) that is blocking stabilization (rust-lang#104218))
…ister,wesleywiser Stabilize raw-dylib, link_ordinal, import_name_type and -Cdlltool This stabilizes the `raw-dylib` feature (rust-lang#58713) for all architectures (i.e., `x86` as it is already stable for all other architectures). Changes: * Permit the use of the `raw-dylib` link kind for x86, the `link_ordinal` attribute and the `import_name_type` key for the `link` attribute. * Mark the `raw_dylib` feature as stable. * Stabilized the `-Zdlltool` argument as `-Cdlltool`. * Note the path to `dlltool` if invoking it failed (we don't need to do this if `dlltool` returns an error since it prints its path in the error message). * Adds tests for `-Cdlltool`. * Adds tests for being unable to find the dlltool executable, and dlltool failing. * Fixes a bug where we were checking the exit code of dlltool to see if it failed, but dlltool always returns 0 (indicating success), so instead we need to check if anything was written to `stderr`. NOTE: As previously noted (rust-lang#104218 (comment)) using dlltool within rustc is temporary, but this is not the first time that Rust has added a temporary tool use and argument: rust-lang#104218 (comment) Big thanks to `@tbu-` for the first version of this PR (rust-lang#104218)
…ister,wesleywiser Stabilize raw-dylib, link_ordinal, import_name_type and -Cdlltool This stabilizes the `raw-dylib` feature (rust-lang#58713) for all architectures (i.e., `x86` as it is already stable for all other architectures). Changes: * Permit the use of the `raw-dylib` link kind for x86, the `link_ordinal` attribute and the `import_name_type` key for the `link` attribute. * Mark the `raw_dylib` feature as stable. * Stabilized the `-Zdlltool` argument as `-Cdlltool`. * Note the path to `dlltool` if invoking it failed (we don't need to do this if `dlltool` returns an error since it prints its path in the error message). * Adds tests for `-Cdlltool`. * Adds tests for being unable to find the dlltool executable, and dlltool failing. * Fixes a bug where we were checking the exit code of dlltool to see if it failed, but dlltool always returns 0 (indicating success), so instead we need to check if anything was written to `stderr`. NOTE: As previously noted (rust-lang#104218 (comment)) using dlltool within rustc is temporary, but this is not the first time that Rust has added a temporary tool use and argument: rust-lang#104218 (comment) Big thanks to ``@tbu-`` for the first version of this PR (rust-lang#104218)
…ister,wesleywiser Stabilize raw-dylib, link_ordinal, import_name_type and -Cdlltool This stabilizes the `raw-dylib` feature (rust-lang#58713) for all architectures (i.e., `x86` as it is already stable for all other architectures). Changes: * Permit the use of the `raw-dylib` link kind for x86, the `link_ordinal` attribute and the `import_name_type` key for the `link` attribute. * Mark the `raw_dylib` feature as stable. * Stabilized the `-Zdlltool` argument as `-Cdlltool`. * Note the path to `dlltool` if invoking it failed (we don't need to do this if `dlltool` returns an error since it prints its path in the error message). * Adds tests for `-Cdlltool`. * Adds tests for being unable to find the dlltool executable, and dlltool failing. * Fixes a bug where we were checking the exit code of dlltool to see if it failed, but dlltool always returns 0 (indicating success), so instead we need to check if anything was written to `stderr`. NOTE: As previously noted (rust-lang#104218 (comment)) using dlltool within rustc is temporary, but this is not the first time that Rust has added a temporary tool use and argument: rust-lang#104218 (comment) Big thanks to ```@tbu-``` for the first version of this PR (rust-lang#104218)
…ister,wesleywiser Stabilize raw-dylib, link_ordinal, import_name_type and -Cdlltool This stabilizes the `raw-dylib` feature (rust-lang#58713) for all architectures (i.e., `x86` as it is already stable for all other architectures). Changes: * Permit the use of the `raw-dylib` link kind for x86, the `link_ordinal` attribute and the `import_name_type` key for the `link` attribute. * Mark the `raw_dylib` feature as stable. * Stabilized the `-Zdlltool` argument as `-Cdlltool`. * Note the path to `dlltool` if invoking it failed (we don't need to do this if `dlltool` returns an error since it prints its path in the error message). * Adds tests for `-Cdlltool`. * Adds tests for being unable to find the dlltool executable, and dlltool failing. * Fixes a bug where we were checking the exit code of dlltool to see if it failed, but dlltool always returns 0 (indicating success), so instead we need to check if anything was written to `stderr`. NOTE: As previously noted (rust-lang#104218 (comment)) using dlltool within rustc is temporary, but this is not the first time that Rust has added a temporary tool use and argument: rust-lang#104218 (comment) Big thanks to ````@tbu-```` for the first version of this PR (rust-lang#104218)
…ister,wesleywiser Stabilize raw-dylib, link_ordinal, import_name_type and -Cdlltool This stabilizes the `raw-dylib` feature (rust-lang#58713) for all architectures (i.e., `x86` as it is already stable for all other architectures). Changes: * Permit the use of the `raw-dylib` link kind for x86, the `link_ordinal` attribute and the `import_name_type` key for the `link` attribute. * Mark the `raw_dylib` feature as stable. * Stabilized the `-Zdlltool` argument as `-Cdlltool`. * Note the path to `dlltool` if invoking it failed (we don't need to do this if `dlltool` returns an error since it prints its path in the error message). * Adds tests for `-Cdlltool`. * Adds tests for being unable to find the dlltool executable, and dlltool failing. * Fixes a bug where we were checking the exit code of dlltool to see if it failed, but dlltool always returns 0 (indicating success), so instead we need to check if anything was written to `stderr`. NOTE: As previously noted (rust-lang#104218 (comment)) using dlltool within rustc is temporary, but this is not the first time that Rust has added a temporary tool use and argument: rust-lang#104218 (comment) Big thanks to `````@tbu-````` for the first version of this PR (rust-lang#104218)
…ister,wesleywiser Stabilize raw-dylib, link_ordinal, import_name_type and -Cdlltool This stabilizes the `raw-dylib` feature (rust-lang#58713) for all architectures (i.e., `x86` as it is already stable for all other architectures). Changes: * Permit the use of the `raw-dylib` link kind for x86, the `link_ordinal` attribute and the `import_name_type` key for the `link` attribute. * Mark the `raw_dylib` feature as stable. * Stabilized the `-Zdlltool` argument as `-Cdlltool`. * Note the path to `dlltool` if invoking it failed (we don't need to do this if `dlltool` returns an error since it prints its path in the error message). * Adds tests for `-Cdlltool`. * Adds tests for being unable to find the dlltool executable, and dlltool failing. * Fixes a bug where we were checking the exit code of dlltool to see if it failed, but dlltool always returns 0 (indicating success), so instead we need to check if anything was written to `stderr`. NOTE: As previously noted (rust-lang#104218 (comment)) using dlltool within rustc is temporary, but this is not the first time that Rust has added a temporary tool use and argument: rust-lang#104218 (comment) Big thanks to ``````@tbu-`````` for the first version of this PR (rust-lang#104218)
This stabilizes the raw-dylib and link_ordinal features (#58713) for the remaining architecture: x86.