Do not use dlltool to create DLL Import Libraries for Windows

[jfgoog]

Motivation and context: #147229

[rustbot]

Some changes occurred in compiler/rustc_codegen_ssa

cc @WaffleLapkin

These commits modify compiler targets.
(See the Target Tier Policy.)

[rustbot]

r? @davidtwco

rustbot has assigned @davidtwco.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

[bjorn3]

As I understand it, this will break support for binutils < 2.40.

View changes since this review

[bjorn3]

This is a stable option, so it can't be removed, only deprecated and ignored.

[jfgoog]

As I understand it, this will break support for binutils < 2.40.

Yes. This change was suggested in the discussion on the bug report, but landing is uncertain and complicated. I wanted to send a change anyway as a concrete point of discussion.

[davidtwco]

r? @wesleywiser

[rustbot]

wesleywiser is currently at their maximum review capacity.
They may take a while to respond.

[bors]

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

[wesleywiser]

*-windows-gnu is not really something I'm familiar with or able to maintain. @mati865 do you have any opinions (not sure if this has any impact on the *-windows-gnullvm targets)?

[workingjubilee]

@wesleywiser Not Mati, but to follow up on the discussion earlier: I asked the MSYS2 folks and they've been packaging binutils 2.40 since 2023-02-03. It apparently actually shipped slightly earlier for Cygwin. For people cross-compiling using mingw toolchains, which we don't quite officially support anyway, well, Debian Bookworm released in 2023-06-10 with it, and we've already seen Debian Trixie.

So the primary users of windows-gnu-type-stuff have been using this binutils for quite some time.

[mati865]

not sure if this has any impact on the *-windows-gnullvm targets)?

I'll tackle the easy part first. This has zero impact on *-windows-gnullvm, it even would bring *-windows-gnu targets closer to *-windows-gnullvm.

@mati865 do you have any opinions

Then there is the hard part (the one without llvm suffix). AFAICT x86_64-pc-windows-gnu is the only tier 1 target/host that doesn't specify supported versions for mingw-w64 and GNU tools. So, far such issues were not very actionable on Rust's side, so the recommendation was just to upgrade, also indicating versions used by Rust's CI.
This time things are a bit different because it (mostly) works with older GNU tools, at the cost of complexity for Rust by maintaining this dlltools workaround/hack. So, the breakage would be a Rust's decision to reduce the complexity.

Unblocking this would require declaring supported toolchains, waiting some grace period, performing the change, and finally dealing with the breakage.

[apiraino]

checking progress. @mati865 just to understand, is this (still) blocked on binutils?

thanks for an update

[mati865]

@apiraino it's fixed in binutils 2.40. Rust doesn't declare minimal supported version, so it's unclear how long should we wait before breaking compatibility with older tools.

[apiraino]

Thanks. Let's talk about this in the triage meeting on Zulip. Feel free to chime in if you have a bit of time :)

[mati865]

I'm often present but today I'm out of home and won't be able to attend.

[wesleywiser]

We discussed this in today's compiler team triage meeting. The consensus from the meeting was that we're open to this change and thus, raising the minimum supported binutils version for the *-windows-gnu targets. We believe the best way to go about this is to:

1. Open an MCP for explicitly specifying the toolchain baseline minimum version for {x86_64,i686}-pc-windows-gnu, with a planned advance blog post over 1/2/3 (?) release cycles + the target stable version for carrying out the eventual change
2. FCP that
3. Open a PR to update the target support docs baseline versions (could be done as part of this PR)
4. (At least 1 stable version in advance) Announce the change via a blog post
5. (N-1 stable release) Ensure compat relnotes mention the pending change
6. Release stable with the change