Can't run x86_64-pc-windows-gnu dev binary with wine

[Emilgardis]

Users have reported being unable to run x86_64-pc-windows-gnu binaries in dev profile with 1.86 via cross using wine. I've confirmed the issue happens outside cross with wine-9.0, cross uses wine-7. I've not been able to confirm the issue happens with any other pc-windows-gnu linkers.

I've not been able to test wine-10

issue in cross-rs cross-rs/cross#1637

The problem is

$ wine target\x86_64-pc-windows-gnu\debug\windows-exe-format-cross-issue1637.exe
Application could not be started, or no application associated with the specified file.
ShellExecuteEx failed: Bad EXE format for Z:\target\x86_64-pc-windows-gnu\debug\windows-exe-format-cross-issue1637.exe.

and seems to come from #135790

emil@Ubuntu-2110-impish-amd64-base:~/windows-exe-format-cross-issue1637$ cross +1.86 run --target x86_64-pc-windows-gnu
   Compiling windows-exe-format-cross-issue1637 v0.1.0 (/home/emil/windows-exe-format-cross-issue1637)
    Finished `dev` profile [unoptimized + debuginfo] target(s) in 0.17s
     Running `env -u CARGO_TARGET_X86_64_PC_WINDOWS_GNU_RUNNER wine /target/x86_64-pc-windows-gnu/debug/windows-exe-format-cross-issue1637.exe`
wine: failed to start L"Z:\\target\\x86_64-pc-windows-gnu\\debug\\windows-exe-format-cross-issue1637.exe"
Application could not be started, or no application associated with the specified file.
ShellExecuteEx failed: Bad EXE format for Z:\target\x86_64-pc-windows-gnu\debug\windows-exe-format-cross-issue1637.exe.

emil@Ubuntu-2110-impish-amd64-base:~/windows-exe-format-cross-issue1637$ cross +1.86 run --target x86_64-pc-windows-gnu --release
   Compiling windows-exe-format-cross-issue1637 v0.1.0 (/home/emil/windows-exe-format-cross-issue1637)
    Finished `release` profile [optimized] target(s) in 0.15s
     Running `env -u CARGO_TARGET_X86_64_PC_WINDOWS_GNU_RUNNER wine /target/x86_64-pc-windows-gnu/release/windows-exe-format-cross-issue1637.exe`
Hello, world!

bisect-rustc

searched nightlies: from nightly-2025-01-03 to nightly-2025-02-15
regressed nightly: nightly-2025-01-24
searched commit range: 649b995...99768c8
regressed commit: 99768c8

bisected with cargo-bisect-rustc v0.6.9

Host triple: x86_64-unknown-linux-gnu
Reproduce with:

cargo install cross https://github.com/cross-rs/cross
echo '#!/usr/bin/env bash
export CROSS_CUSTOM_TOOLCHAIN=1
cross run --target x86_64-pc-windows-gnu
' > cross-run.sh
chmod +x cross-run.sh
cargo bisect-rustc --target x86_64-pc-windows-gnu --script cross-run.sh --start 1.85.0 --end 1.86.0 

@rustbot modify labels: +regression-from-stable-to-stable -regression-untriaged

[workingjubilee]

WINE is a compatibility layer for what we would call "pc-windows-msvc". The only change in those commits is we started marking the debuginfo as DWARF, but that's because we do in fact use DWARF debuginfo for GNU targets. It is likely that WINE is identifying a binary that has some slightly changed metadata in a header somewhere and rejecting it needlessly.

These binaries still run on Windows platforms, so please file a bug with WINE.

[Emilgardis]

Thank you for the insight about what the change did. I got the impression that we changed from pdb to dwarf.

[workingjubilee]

A marker in a binary identifying the debuginfo may have changed, but the actual debuginfo used stayed the same. It was always DWARF. There's basically three possibilities, here, because the basic facts of the matter is "Windows accepts, but WINE rejects":

1. We altered the header to include or omit data in a way that ought to be inconsequential.
2. We have mangled something that Windows has rejected in the past.
3. We have mangled something that Windows should reject in the future.

I think we can dismiss the third on the basis that it is simply difficult to know the future, unless we can identify a strong precedent otherwise.

If the second case is what happened, it would almost certainly have to be because we hit a codepath in LLVM that triggers UB or incur some invalid behavior. However, in general, we build our LLVM to trap on hitting what would otherwise be UB codepaths in LLVM. So the only thing that would trigger 2 would be a deliberate but invalid behavior, in which case we may have to file an LLVM bug, or adjust how we use it, depending.

For the first, though, either WINE should fix it, or they should reject fixing it for some reason or another, like "we don't deliberately support Windows/GNU binaries". They can also just tell me why I'm wrong or why the change was actually fundamentally incorrect, despite having no observable differences on the actual Windows platform.

The change was pretty trivial so we could revert it without much consequence, but it has already hit stable instead of being reported during beta or nightly. We should have a reason slightly better than "external software that tries to replicate the behavior of another platform is apparently not replicating the behavior of that platform".

[mati865]

WINE is a compatibility layer for what we would call "pc-windows-msvc".

I beg to differ.
Wine works fine for binaries created using any combination of Rust/C/C++/... and msvc/gnu/"gnullvm". In fact, it's commonly (at least in gnu/"gnullvm" world) used to debug cases when a compiler goes south and resulting binaries stop working.
People developing mingw-w64 and related GCC/LLVM toolchains not only use it but also contribute there, it has also helped with more than a few issues affecting Rust windows-gnu targets.

One of the reasons for that, is the ability to tell Wine to log very low level stuff (from OS perspective). Obviously, it's not possible on Windows.

These binaries still run on Windows platforms, so please file a bug with WINE.

If they do work (I did not test cross outputs on Windows), then indeed it should be reported to Wine, but also double-checked on Rust side (or rather cross side) if everything's fine. After all, these changes (combined with #135739) were a refactor/simplification.

Different targets without cross on Arch Linux:

❯ cargo new hello --bin
    Creating binary (application) `hello` package
note: see more `Cargo.toml` keys and their definitions at https://doc.rust-lang.org/cargo/reference/manifest.html

❯ cd hello/

❯ bat --terminal-width 40 src/main.rs
───────┬────────────────────────────────
       │ File: src/main.rs
───────┼────────────────────────────────
   1   │ fn main() {
   2   │     println!("Hello, world!");
   3   │ }
───────┴────────────────────────────────

❯ cargo b --target x86_64-pc-windows-gnu
   Compiling hello v0.1.0 (/tmp/hello)
    Finished `dev` profile [unoptimized + debuginfo] target(s) in 0.08s

❯ wine target/x86_64-pc-windows-gnu/debug/hello.exe
00b8:fixme:wineusb:query_id Unhandled ID query type 0x5.
00b8:fixme:wineusb:query_id Unhandled ID query type 0x5.
00b8:fixme:wineusb:query_id Unhandled ID query type 0x5.
00b8:fixme:wineusb:query_id Unhandled ID query type 0x5.
00b8:fixme:wineusb:query_id Unhandled ID query type 0x5.
00b8:fixme:wineusb:query_id Unhandled ID query type 0x5.
Hello, world!

❯ PATH=/opt/llvm-mingw/llvm-mingw-ucrt/bin:$PATH RUSTFLAGS=-Ctarget-feature=+crt-static cargo b --target=x86_64-pc-windows-gnullvm
   Compiling hello v0.1.0 (/tmp/hello)
    Finished `dev` profile [unoptimized + debuginfo] target(s) in 0.06s

❯ wine target/x86_64-pc-windows-gnullvm/debug/hello.exe
00b8:fixme:wineusb:query_id Unhandled ID query type 0x5.
00b8:fixme:wineusb:query_id Unhandled ID query type 0x5.
00b8:fixme:wineusb:query_id Unhandled ID query type 0x5.
00b8:fixme:wineusb:query_id Unhandled ID query type 0x5.
00b8:fixme:wineusb:query_id Unhandled ID query type 0x5.
00b8:fixme:wineusb:query_id Unhandled ID query type 0x5.
Hello, world!

❯ PATH=/opt/llvm-mingw/llvm-mingw-ucrt/bin:$PATH cargo b --target=x86_64-pc-windows-gnullvm
   Compiling hello v0.1.0 (/tmp/hello)
    Finished `dev` profile [unoptimized + debuginfo] target(s) in 0.05s

❯ WINEPATH=/opt/llvm-mingw/llvm-mingw-ucrt/x86_64-w64-mingw32/bin wine target/x86_64-pc-windows-gnullvm/debug/hello.exe
00b8:fixme:wineusb:query_id Unhandled ID query type 0x5.
00b8:fixme:wineusb:query_id Unhandled ID query type 0x5.
00b8:fixme:wineusb:query_id Unhandled ID query type 0x5.
00b8:fixme:wineusb:query_id Unhandled ID query type 0x5.
00b8:fixme:wineusb:query_id Unhandled ID query type 0x5.
00b8:fixme:wineusb:query_id Unhandled ID query type 0x5.
Hello, world!

cross (fresh run after a warm-up) on the same system:

❯ PATH=/opt/llvm-mingw/llvm-mingw-ucrt/bin:$PATH cross run  --target=x86_64-pc-windows-gnu
info: syncing channel updates for 'stable-x86_64-unknown-linux-gnu'

  stable-x86_64-unknown-linux-gnu unchanged - rustc 1.86.0 (05f9846f8 2025-03-31)

info: self-update is disabled for this build of rustup
info: any updates to rustup will need to be fetched with your system package manager
Emulate Docker CLI using podman. Create /etc/containers/nodocker to quiet msg.
   Compiling hello v0.1.0 (/project)
    Finished `dev` profile [unoptimized + debuginfo] target(s) in 0.10s
     Running `env -u CARGO_TARGET_X86_64_PC_WINDOWS_GNU_RUNNER wine /target/x86_64-pc-windows-gnu/debug/hello.exe`
wine: failed to start L"Z:\\target\\x86_64-pc-windows-gnu\\debug\\hello.exe"
Application could not be started, or no application associated with the specified file.
ShellExecuteEx failed: Bad EXE format for Z:\target\x86_64-pc-windows-gnu\debug\hello.exe.

# cross doesn't support gnullvm, so I had no way to thest them

[mati865]

Update:
I have also tested binaries created from Arch Linux on Windows 11, and they behave the same way as with Wine:

$ /c/normal.exe
Hello, world!

$ /c/cross.exe
bash: /c/cross.exe: cannot execute binary file: Exec format error

So it's not Wine issue but cross issue.

[Emilgardis]

Thanks @mati865 , as I said/suggested in the OP I haven't been able to make a proper gnu toolchain yet on a standalone device, but that suggests to me it's some dependency we have doing something wonky. I'll close this issue and continue in cross-rs/cross#1637