rust-assert-no-alloc
rust-assert-no-alloc copied to clipboard
Windfisch
applications don't start with x86_64-pc-windows-gnu
Investigating the feasibility of cross compiling my application from Linux to Windows to find out if I'll need Windows for CI, I tried building for the x86_64-pc-windows-gnu target and running the executable in my Windows VM. However, my application just hangs on startup. Even putting println! as the very first line of main does nothing. When I commented out setting the global allocator to AllocDisabler, it worked both in my Windows VM and WINE.
Guarding the #[global_allocator] with #[cfg(not(all(windows, target_env = "gnu")))] hacks around the problem. Of course that isn't great if you're doing development with MinGW.
I also noticed this issue a while back when cross compiling libraries to x86_64-pc-windows-gnu and running them under Wine, but I assumed this not working was just the result of the combination of those two factors and didn't look into it much further. But as it turns out the same thing happens when you compile and run x86_64-pc-windows-gnu binaries/libraries on native Windows. Has anyone looked into this yet?
Uh, this is weird. Have you tried attaching a debugger to this so you see where exactly it is hanging? Does it hog the CPU or is it just idle?
I don't have a windows system around to test, but can you maybe provide a concrete example how to reproduce this bug under linux/wine? (Including how you set up wine and rust under wine)? Maybe winedbg can help...
It happens on the first allocation. So presumably a program that just creates a Box<u32> and dbg!() prints it should hang. You can cross compile to the x86_64-pc-windows-gnu target on Linux and run the binary under Wine with winedbg --gdb.