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

[a5ehren]

So I spent my evening poking exes with objdump and found that the outputs from cross have the ".debug_addr" section while cross-compiled exes from cargo do not.

The big thing there is that the presence of ".debug_addr" indicates that split-debuginfo is getting turned on at some point, which should not happen.

A failing exe outputs this line from WINE:
0134:warn:module:map_image_into_view <exe path> section /4 too large (ffc00000+21000/25dc000)

This leads me to believe that something in the cross environment is flipping rustc over to the msvc defaults instead of the proper windows-gnu settings.

Edit: A little extra confirmation - running cross with the 1.85.1 toolchain does not generate the .debug_addr section.

[mati865]

Recently there was another report to the upstream: rust-lang/rust#141096

And finding out the same error was caused by the old toolchain rang a bell for me. Looking at #1667, the toolchain appears to be at least 5 years old, so this is probably one of many Binutils bugs.

Either updating the toolchain or using LLD would solve that problem.

Edit: A little extra confirmation - running cross with the 1.85.1 toolchain does not generate the .debug_addr section.

Oh, I didn't see that before. Is it the only outstanding difference?
I'm certain there was a bug with .debug_addr handing in Binutils at some point, but it was too long ago for me to recall the details. Definitely within the last decade...

[a5ehren]

Their release notes don’t mention it, but I can check the git history later.

[Emilgardis]

Please see the regression search here: #1637 (comment)