Stabilize raw_dylib (`#[link(kind = "raw-dylib")]`) #104218

tbu- · 2022-11-09T21:51:14Z

This stabilizes the raw-dylib and link_ordinal features (#58713) for the remaining architecture: x86.

rustbot · 2022-11-09T21:51:21Z

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.

tbu- · 2022-11-09T21:55:09Z

Stabilization proposed in #58713 (comment).

The remaining mentions of raw_dylib are in src/tools/rust-analyzer. I assumed that I should not modify that because rust-analyzer has its own repository.

dpaoliello · 2022-11-09T22:11:14Z

r? @michaelwoerister

This stabilizes the raw-dylib and link_ordinal features (rust-lang#58713) for the remaining architecture: x86.

michaelwoerister · 2022-11-11T08:48:23Z

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.

michaelwoerister · 2022-11-14T11:12:08Z

Thanks for the PR, @tbu-!

I have some comments:

Can you please post a stabilization report to the tracking issue, listing the things that are added here on top of the previous stabilization?
@dpaoliello has fixed the x86 name decoration problem in raw-dylib feature does not support all cases for stdcall functions on i686-pc-windows-* #96534. However, I'm not sure if @joshtriplett's comment already counts as a lang-team approval for the import_name_type attribute (the compiler team already approved it via MCP 525). But I think we'll need to add the lang-team to the FCP anyway.
Cross-compiling from x86_64-pc-windows-gnu to i686-pc-windows-gnu does not work yet, as reported in Cross-compiling raw-dylib doesn't work on Windows #103939 by @mati865. This doesn't seem like an uncommon scenario, and I think we should have at least a PR with a fix before starting an FCP.
The Rust Reference needs to be updated. This is the original PR introducing documentation: Add documentation for raw-dylib and link_ordinal reference#1244
An i686-specific issue with vectorcall has been fixed in Add tests for raw-dylib with vectorcall, and fix vectorcall code generation #99476.
We have some evidence that the feature works as expected for the windows-rs crate in Experimental raw-dylib support microsoft/windows-rs#2149. That's great news since windows-rs is likely to be a great stress test for the feature.
It looks like rust-analyzer does indeed have test cases that will need to be updated. My guess is that @rust-lang/wg-rls-2 will take care of that once the stabilization is through.

dpaoliello · 2022-11-15T18:24:27Z

One more issue blocking stabilization for x86 (I'm currently looking into it): #104453

kennykerr · 2022-11-15T18:53:54Z

Cross-compilation would also block windows-rs from going beyond experimental support. #103939

mati865 · 2022-11-15T21:38:35Z

Cross-compiling from x86_64-pc-windows-gnu to i686-pc-windows-gnu does not work yet, as reported in Cross-compiling raw-dylib doesn't work on Windows #103939 by @mati865. This doesn't seem like an uncommon scenario, and I think we should have at least a PR with a fix before starting an FCP.

@michaelwoerister I think there is one more problem related to the mentioned issue that maybe even should have blocked stabilization on 64-bit platforms.
rustc has dlltool flag to override path to dlltool binary which could have been used as a workaround to this issue. Sound cool but that flag is unstable (-Z dlltool) so on windows-gnu users can override things like linker but are stuck with first dlltool binary that is found in PATH with no ability to change it.
Both current dlltool hack and this flag are "temporary" until Rust can declare minimal supported Binutils version for windows-gnu recent enough it contains fix allowing it to link against short import libraries created by LLVM (this fix will be included in upcoming 2.40 version). Then the hack will become obsolete since all targets would use LLVM to generate import libs and and the flag will become obsolete.

michaelwoerister · 2022-11-17T13:29:18Z

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 -C dlltool commandline option (unless we come up with a foolproof way of always finding the correct dlltool -- which we didn't 😉). When the option was introduced in #90782, I asked on Zulip what the procedure would be here. That feedback was that we can just make the flag part of the stabilization FCP. So, I think we just have to make it visible in the stabilization report, that -Z dlltool becomes -C dlltool.

But one open question there is if rustc should always use the specified dlltool if the option is explicitly set, even when it would normally go through LLVM. I think the answer is yes, because otherwise it would be confusing.

bjorn3 · 2022-11-17T13:38:26Z

I think -Cdlltool should only be respected if rustc itself can't do it. This is similar to how we used to invoke an external archiver that you could specify using -Car, but have since deprecated this option and started ignoring it's value since rustc can do it on it's own now.

michaelwoerister · 2022-11-17T14:10:28Z

I think that would be confusing, no? If I explicitly add -C dlltool to my rustc invocation, I would expect it to use the tool I specified unconditionally (as opposed to "just some of the time under conditions that are undocumented implementation details"). My expectations would be different if the commandline option was called something like -C fallback-dlltool.

bjorn3 · 2022-11-17T14:28:03Z

My suggestion is to stabilize -Cdlltool for now, but deprecate and ignore it once rustc has builtin support. This won't be the first case where rustc temporarily used an external tool until we gained builtin support. Keeping the external tool support only harms maintainability without any advantages that I know of.

-Car: deprecated and value ignored
cg_gcc uses ranlib: Rewrite LLVM's archive writer in Rust #97485 should remove this
-Zno-integrated-as: removed in Remove no_integrated_as mode. #70345
dwarf split debuginfo: moved from llvm-dwp to the thorin crate before cg: split dwarf for crate dependencies #89819 was merged, but if that happened would likely have done so afterwards.

michaelwoerister · 2022-11-17T14:59:15Z

OK, I have no strong opinion here. Being able to remove the entire dlltool logic at some point does seem like an advantage. We just have to make sure to clearly document what the commandline option really does.

bors · 2022-11-28T17:19:09Z

☔ The latest upstream changes (presumably #105008) made this pull request unmergeable. Please resolve the merge conflicts.

apiraino · 2023-01-05T14:26:13Z

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 ready, thanks!

@rustbot author

Dylan-DPC · 2023-03-01T12:07:47Z

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)

rustbot assigned ehuss Nov 9, 2022

rustbot added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. labels Nov 9, 2022

tbu- force-pushed the pr_stabilize_raw_dylib branch from af71c84 to 97dc3f9 Compare November 9, 2022 21:53

tbu- mentioned this pull request Nov 9, 2022

Tracking issue for RFC 2627: #[link(kind="raw-dylib")] #58713

Open

15 tasks

tbu- force-pushed the pr_stabilize_raw_dylib branch from 97dc3f9 to e981b46 Compare November 9, 2022 22:08

dpaoliello approved these changes Nov 9, 2022

View reviewed changes

rustbot assigned michaelwoerister and unassigned ehuss Nov 9, 2022

This comment has been minimized.

Sign in to view

Stabilize raw_dylib (#[link(kind = "raw-dylib")])

ec4d15d

This stabilizes the raw-dylib and link_ordinal features (rust-lang#58713) for the remaining architecture: x86.

tbu- force-pushed the pr_stabilize_raw_dylib branch from e981b46 to ec4d15d Compare November 10, 2022 00:37

crlf0710 added the F-raw_dylib `#![feature(raw_dylib)]` label Nov 10, 2022

messense mentioned this pull request Nov 23, 2022

pyo3-ffi: raw-dylib support PyO3/pyo3#2775

Open

rustbot removed the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Jan 5, 2023

rustbot added the S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. label Jan 5, 2023

dpaoliello mentioned this pull request Feb 22, 2023

Fix cross-compiling with dlltool for raw-dylib #108355

Merged

Dylan-DPC closed this Mar 1, 2023

This was referenced Mar 24, 2023

Stabilize -Cdlltool #109575

Closed

Stabilize raw-dylib, link_ordinal, import_name_type and -Cdlltool #109677

Merged

dpaoliello mentioned this pull request Aug 2, 2023

Cross-compiling raw-dylib doesn't work on Windows #103939

Open

dpaoliello mentioned this pull request Aug 16, 2024

Add an optional COMDAT record for the .idata$3 section rust-lang/ar_archive_writer#20

Merged

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Stabilize raw_dylib (`#[link(kind = "raw-dylib")]`) #104218

Stabilize raw_dylib (`#[link(kind = "raw-dylib")]`) #104218

tbu- commented Nov 9, 2022 •

edited

Loading

rustbot commented Nov 9, 2022

tbu- commented Nov 9, 2022

dpaoliello commented Nov 9, 2022

This comment has been minimized.

michaelwoerister commented Nov 11, 2022 •

edited

Loading

michaelwoerister commented Nov 14, 2022

dpaoliello commented Nov 15, 2022

kennykerr commented Nov 15, 2022

mati865 commented Nov 15, 2022

michaelwoerister commented Nov 17, 2022

bjorn3 commented Nov 17, 2022

michaelwoerister commented Nov 17, 2022

bjorn3 commented Nov 17, 2022

michaelwoerister commented Nov 17, 2022

bors commented Nov 28, 2022

apiraino commented Jan 5, 2023

Dylan-DPC commented Mar 1, 2023

Stabilize raw_dylib (#[link(kind = "raw-dylib")]) #104218

Stabilize raw_dylib (#[link(kind = "raw-dylib")]) #104218

Conversation

tbu- commented Nov 9, 2022 • edited Loading

rustbot commented Nov 9, 2022

tbu- commented Nov 9, 2022

dpaoliello commented Nov 9, 2022

This comment has been minimized.

michaelwoerister commented Nov 11, 2022 • edited Loading

michaelwoerister commented Nov 14, 2022

dpaoliello commented Nov 15, 2022

kennykerr commented Nov 15, 2022

mati865 commented Nov 15, 2022

michaelwoerister commented Nov 17, 2022

bjorn3 commented Nov 17, 2022

michaelwoerister commented Nov 17, 2022

bjorn3 commented Nov 17, 2022

michaelwoerister commented Nov 17, 2022

bors commented Nov 28, 2022

apiraino commented Jan 5, 2023

Dylan-DPC commented Mar 1, 2023

Stabilize raw_dylib (`#[link(kind = "raw-dylib")]`) #104218

Stabilize raw_dylib (`#[link(kind = "raw-dylib")]`) #104218

tbu- commented Nov 9, 2022 •

edited

Loading

michaelwoerister commented Nov 11, 2022 •

edited

Loading