Combining native-windows-gui and tokio
from modulus@lemmy.ml to rust@programming.dev on 09 Oct 2023 08:39 +0000
https://lemmy.ml/post/6235538
from modulus@lemmy.ml to rust@programming.dev on 09 Oct 2023 08:39 +0000
https://lemmy.ml/post/6235538
Hi there,
I’m trying to do some native windows rust programming. I’m using native-windows-gui and native-windows-derive to do it, but if I try to mix that with tokio, I get the following:
No entry point found error for GetWindowSubclass. On console, I get:
error: process didn't exit successfully: `C:\source\myprojectanem\target\debug\myprojectname.exe` (exit code: 0xc0000139, STATUS_ENTRYPOINT_NOT_FOUND)
If I change
#[tokio::main] async fn main() {
to:
fn main() {
The problem goes away, but obviously I can’t use tokio then.
Any clue what the problem is and how to fix it?
#rust
You can manually convert a
tokio::main
to a regularmain
by constructing a tokio runtime and telling it to block on a top-level future (e.g. an async block).tokio.rs/tokio/tutorial/hello-tokio
That will at least help you break down the problem to locate the issue.
I don’t know anything about Windows though. Maybe there’s some per-thread setup that needs to be done in tokio’s thread pool?
Same erro by using this approach.
Tokio works fine, by itself. windows-native-gui works fine, by itself. It is the combination that causes this issue.
Apparently the problem is due to an incompatibility between the use of certain libraries (winapi and windows-sys) which use different versions of COM. At least so I deduce from the documentation I’ve read.
There’s a workaaround:
On Cargo.toml, use.
And on the root of the project (not the src dir) create a build.rs file with the following content:
This embeds a manifest together with the executable, solving the issue.
wouldn’t it be better to use
#[cfg(target_os = “windows”)]
instead of checking an env variable?Reference: doc.rust-lang.org/rust-by-example/…/cfg.html
Possibly yes. I’ll check if the results are equivalent.