cross run and cross test failed with Bad EXE format for target x86_64-pc-windows-gnu

[eareimu]

reimu@ea ~/code> cargo new --lib syt; cd syt
reimu@ea ~/c/syt (main)> cross test  --target=x86_64-pc-windows-gnu
info: syncing channel updates for 'nightly-x86_64-unknown-linux-gnu'

  nightly-x86_64-unknown-linux-gnu unchanged - rustc 1.87.0-nightly (b74da9613 2025-03-06)

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
   Compiling syt v0.1.0 (/home/reimu/code/syt)
    Finished `test` profile [unoptimized + debuginfo] target(s) in 0.07s
     Running unittests src/lib.rs (/target/x86_64-pc-windows-gnu/debug/deps/syt-b5735c119cfe9f2a.exe)
wine: failed to start L"Z:\\target\\x86_64-pc-windows-gnu\\debug\\deps\\syt-b5735c119cfe9f2a.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\deps\syt-b5735c119cfe9f2a.exe.

error: test failed, to rerun pass `--lib`

Caused by:
  process didn't exit successfully: `env -u CARGO_TARGET_X86_64_PC_WINDOWS_GNU_RUNNER wine /target/x86_64-pc-windows-gnu/debug/deps/syt-b5735c119cfe9f2a.exe` (exit status: 1)
note: test exited abnormally; to see the full output pass --nocapture to the harness.

oh, why?

then I also tried cargo run:

reimu@ea ~/c/syt (main) [1]> cd ..
reimu@ea ~/code> cargo new --bin syt1;cd syt1
    Creating binary (application) `syt1` package
note: see more `Cargo.toml` keys and their definitions at https://doc.rust-lang.org/cargo/reference/manifest.html
reimu@ea ~/c/syt1 (main)> cross run  --target=x86_64-pc-windows-gnu
info: syncing channel updates for 'nightly-x86_64-unknown-linux-gnu'

  nightly-x86_64-unknown-linux-gnu unchanged - rustc 1.87.0-nightly (b74da9613 2025-03-06)

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
   Compiling syt1 v0.1.0 (/home/reimu/code/syt1)
    Finished `dev` profile [unoptimized + debuginfo] target(s) in 0.05s
     Running `env -u CARGO_TARGET_X86_64_PC_WINDOWS_GNU_RUNNER wine /target/x86_64-pc-windows-gnu/debug/syt1.exe`
wine: failed to start L"Z:\\target\\x86_64-pc-windows-gnu\\debug\\syt1.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\syt1.exe.

reimu@ea ~/c/syt1 (main) [1]> 

[justsmth]

I'm also now seeing this. I suspect it's related to a change made to the compiler in 1.86.0, as the last successful run for the CI job was April 2, the day before 1.86.0 released.

Edit: I also see a similar question asked today on StackOverflow: https://stackoverflow.com/questions/79553416/can-no-more-cross-compile-using-cross-run

[Emilgardis]

I wonder if this is the same issue as initially posted. Anyway! we can do a bisect with rustc bisect, ill see if I have time this weekend to do that, otherwise id appreciate some help.

That SO post looks like #1657

[Emilgardis]

searched nightlies: from nightly-2025-01-03 to nightly-2025-02-15
regressed nightly: nightly-2025-01-24
searched commit range: rust-lang/rust@649b995...99768c8
regressed commit: rust-lang/rust@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
cargo new cross-issue1637
cd cross-issue1637
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 

this is most likely rust-lang/rust#135790 , which matches up with release profile working but not dev profile

Unsure if this is a regression in rust or that we're doing something wonky with wine. To me it looks like a rust regression so I'll submit an issue upstream

[Emilgardis]

The issue is most likely not due to rustc doing something wrong but wine misinterpreting the header (and/or debuginfo).

To solve this, we should identify what changed syntatically in the binary after rust-lang/rust@99768c8 and then file a report to the wine maintainers

To research this, I'd suggest loading a binary into ghidra or similar tool. As I mentioned, I can't specifically dedicate much time to this this week, one workaround should be to strip the binary (haven't tested this)

[Emilgardis]

It has been more or less confirmed that this is a cross issue and not wine, with the binaries created by cross failing on real windows.

We probably need to update the gnu toolchain