Panic in new version when cross-compiled to Windows. #470
Comments
|
If compiled in release, does it work? |
|
Compiling various options... |
|
Reproduced this problem with rend3's "cube" example: That's in debug mode. Release mode next. |
|
Compile/link of Rend3 examples failed in release mode cross-compiling to "--target x86_64-pc-windows-gnu --release": Linker in a loop or something. |
|
Try just building a single package without imgui - imgui may not compile under mingw |
|
It used to work. Hang on, I seem to have somehow gotten Rust nightly installed. |
|
OK. Had to reproduce on a machine with more memory. Using current Rust stable on Ubuntu 20.04 LTS and 22.04 LTS.
|
|
Upgraded to Wine 8. Same error, but better messages: This was cross-compiled in debug mode. This version of Wine, like Wine 7.0, will run my full program which uses rend3 rev f2b7df4 So, somewhere in the last few months of Rend3 development, cross-compilation was broken. |
|
Any progress? Able to reproduce this? |
|
Just tested this out. I do get the weird linking errors in release with mingw - I have no idea what cause this as all other platforms link fine. They seem to all be errors linking with other parts of rust, which shouldn't be able to happen using just rust code. Cube debug example runs fine natively on windows though, so it seems like it's something about wine or the act of cross compilation that's messing it up. I don't have a way of testing wine (as I don't have any linux machines right now). So the error seems to be from the shader loader code not being able to find the shader files. Could you add a |
|
Ah. Added appropriate "expect" calls, and got thread 'main' panicked at 'Unable to get shader file rend3/mipmap.wgsl', rend3/src/shader.rs:64:18 OK, so Rend3, at least in these demos, is looking in for "mipmap.wsgl" and not finding it. Rend3 is using the "rust_embed" crate to embed additional files in the executable, and somehow that didn't work. Let me dig into rust_embed vs Wine and see how that works. rust-embed says that, "Debug builds will read the data from the file system at runtime". I'm trying to figure out which components assume what is supposed to be where. The trouble in debug mode is somewhere in that space. |
|
It's a bug in either Wine or cross-compile or rust-embed. I built the examples for rust-embed, and example "basic" works on Unix but fails under Wine. Exactly the same problem. the "unwrap()" is for That's in debug mode. Release mode, where the file actually gets included in the executable, succeeds. |
|
I think the issue is that rust-embed is calling Path::canonicalize on these paths, but as it is running it as the host (linux) not the cross-compilation target (windows), it produces a folder path which uses |
|
That's reasonably likely. Paths under Wine are kind of strange, because you can access both the Windows and Linux file systems. I filed a bug report on rust-embed.. As for the linker bug with the megabyte-sized error message, I posted this on the Rust forums. It seems to have something to do with core::sync::atomic_load, but the error messages make little sense. Maybe someone else has seen this before. atomic_load is the sort of thing that would have a different implementation in release mode. |
|
Possibly related: two bugs from last year involving atomic_load causing similar linker errors. |
|
See also Rust Bug #98302. This looks likely, and it's way down in LLVM. |
|
Yup, that looks like exactly it - at least you can work around it with fat lto |
|
Yes, |
|
Re rust-embed crash: Right. Under Wine, you can get at the Linux file system, but it's the Z drive. Names relative to the current directory still work, and getting prefixes from the Windows environment works, but what rust-embed is storing is a canonical Unix path meaningful only in the original environment. It looks like you already fixed this problem with "wasm" targets. I see the code in Rend3's Cargo.toml: That's a fix for the same problem I'm having - cross compiling to a different OS. It seems "debug-embed" needs to be enabled for all cross-compiles, not just the "wasm" target". It's cross-compiling that's the problem. (Can you write cfg(target_arch != source_arch) in Cargo files? Probably not. That's the general idea, though.) Minimum support needed is the ability to request feature debug-embed for rust-embed when using Rend3. Can't currently do that as a user of Rend3 without modifying the sources. |
|
Thankfully, you can actually enable features as the end user - if you take a dependency on rust-embed yourself and enable the features, the feature will be enabled for everyone, including rend3. Unfortunately there's no good signal for the true condition: the program will be run on a different (logical) machine than the one it is compiled on. Being compiled in debug is comorbid, but not always the case (as we can clearly see). Ultimately, embedding files is the desired behavior for all users of rend3, as they can't directly modify our shaders. But users may want their own shaders to be read directly for ease of iteration. |
OK, that should work. I misunderstood "feature unification". I was thinking that would load two versions of rust-embed. But apparently not. OK, so now I have workarounds for all these problems and can move forward again. |
|
Closing for now. Workarounds available, and the problems are not in Rend3 but in lower levels. |
Existing program using new Rend3, rev = "6dd847f", works when built on LInux with a Linux target, but if built for a cross-compiled Windows target, crashes under Wine 7.0. This program worked cross platform with version rev = "a972b0ff0a98bb79b2b1c8812e3a823840a5e02e"
Reproduce by:
cd to x86 target dir
wine ui-mock.exeCode from shader.rs is:
Tried to get a backtrace, but in this environment the unwinder blew up and went into a loop that produced a long stream of the same error, then a crash.
The text was updated successfully, but these errors were encountered: