Cargo stale build with WSL2 when cross-compiling for Windows

Hi, first time poster here!

When cross-compiling a Bevy game in WSL2 Ubuntu 22.04 to Windows 11, I noticed my build is stale. Any changes I have made since my first compilation of the day will not be reflected when running the app. For example, if I add a simple print, then I won't see the print in my console.

Strangely this persists even through both a cargo clean and a fresh clone from GitHub. I have confirmed my changes are present in the files and that cargo has detected the changes to the file. Even if from Windows 11 I browse to the executable in the File Explorer and run it manually, the executable will be stale.

I run my project by doing cargo run --target x86_64-pc-windows-msvc which produces an executable at target/x86_64-pc-windows-msvc/debug/mygame.exe.

Any tips for how to debug this further?


  • Rust toolchain: stable (1.72.0)
  • LLD: 17.0.0
  • Bevy: 0.11.2
  • xwin: 0.2.14
# .cargo/config.toml
linker = "lld"
rustflags = [
# Cargo.toml
name = "mygame"
version = "0.1.0"
edition = "2021"

bevy = "0.11.2"

# Enable max optimizations for dependencies, but not for our code:
opt-level = 3

# Enable only a small amount of optimization in debug mode
opt-level = 1

please describe your environment setup in detail, for example, where the code is stored, is it on an ext4 file system or a drvfs partition? how do you edit your code, using vscode on windows with wsl remote, or using a Linux editor like neovim? when it comes to unusual and strange behavior like this, every detail can be a clue.

that simply make no sense, did you check after cargo clean, the target directory is indeed deleted? what happens if you cargo run --target x86_64-pc-windows-msvc?

The code is stored on an ext4 file system. My path for the project is ~/dev/games/mygame. Specifically, this is the default file system for WSL2 which is a virtual hard disk.

I use the Helix Editor directly from my WSL2 Terminal. For multi-window editing, I use a terminal multiplexer called Zellij.

Yes, the directory was deleted fully. I agree that this issue does not make sense which is why I turned to the internet for help. I even rm -rf target to wipe the folder entirely. If I run cargo run --target x86_64-pc-windows-msvc after deleting the target, then a full rebuild will happen. However, the produced binary will still be the stale binary.

that's indeed unexplainable. what changes did you make to the code, and what's the expected and actual behavior of the program? maybe we can get some clue from the program itself.

This topic was automatically closed 90 days after the last reply. We invite you to open a new topic if you have further questions or comments.