windows-gnu target can't be emulated arm64 qemu via wine

Question

windows-gnu target can't be emulated arm64 qemu via wine

Emilgardis opened this issue 10 months ago · 12 comments

bash-5.2$ uname -a
Darwin Emils-MacBook-Pro.local 22.1.0 Darwin Kernel Version 22.1.0: Sun Oct  9 20:15:09 PDT 2022; root:xnu-8792.41.9~2/RELEASE_ARM64_T6000 arm64
bash-5.2$ cross build --target x86_64-pc-windows-gnu -v
+ cargo metadata --format-version 1 --filter-platform x86_64-pc-windows-gnu
+ rustc --print sysroot
+ /usr/local/bin/docker
+ /usr/local/bin/docker version -f '{{ .Server.Os }},,,{{ .Server.Arch }}'
[cross] warning: using older rustc `1.71.0 (8ede3aae2 2023-07-12)` for the target. Current active rustc on the host is `rustc 1.72.1 (d5c2e9c34 2023-09-13)`.
 > Update with `rustup update --force-non-host stable-x86_64-unknown-linux-gnu`
+ rustup toolchain list
+ rustup target list --toolchain stable-x86_64-unknown-linux-gnu
+ rustup component list --toolchain stable-x86_64-unknown-linux-gnu
+ /usr/local/bin/docker run --userns host --platform linux/amd64 -e 'PKG_CONFIG_ALLOW_CROSS=1' -e 'XARGO_HOME=/Users/emil/.xargo' -e 'CARGO_HOME=/Users/emil/.cargo' -e 'CROSS_RUST_SYSROOT=/Users/emil/.rustup/toolchains/stable-x86_64-unknown-linux-gnu' -e 'CARGO_TARGET_DIR=/target' -e 'CROSS_RUNNER=' -e TERM -e 'USER=emil' -e 'CROSS_RUSTC_MAJOR_VERSION=1' -e 'CROSS_RUSTC_MINOR_VERSION=71' -e 'CROSS_RUSTC_PATCH_VERSION=0' --name cross-stable-x86_64-unknown-linux-gnu-47e2d-8ede3aae2-x86_64-pc-windows-gnu-50dfa-1700335486570 --rm --user 501:20 -v /Users/emil/.xargo:/Users/emil/.xargo:z -v /Users/emil/.cargo:/Users/emil/.cargo:z -v /Users/emil/.cargo/bin -v /Users/emil/workspace/cross-tests/basic:/Users/emil/workspace/cross-tests/basic:z -v /Users/emil/.rustup/toolchains/stable-x86_64-unknown-linux-gnu:/Users/emil/.rustup/toolchains/stable-x86_64-unknown-linux-gnu:z,ro -v /Users/emil/workspace/cross-tests/basic/target:/target:z -w /Users/emil/workspace/cross-tests/basic -t ghcr.io/cross-rs/x86_64-pc-windows-gnu:main sh -c 'PATH="$PATH":"/Users/emil/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/bin" cargo build --target x86_64-pc-windows-gnu -v'
+ rustup component list --toolchain stable-x86_64-unknown-linux-gnu
bash-5.2$ echo $?
53

there's something wrong with wine through qemu.

Originally posted by @hex-developer in #1371 (comment)

Answer 1 · 2023-11-18T19:33:06.000Z

removed the >/dev/null redirect here

gives

❯ cross build --target x86_64-pc-windows-gnu
[cross] warning: using older rustc `1.71.0 (8ede3aae2 2023-07-12)` for the target. Current active rustc on the host is `rustc 1.72.1 (d5c2e9c34 2023-09-13)`.
 > Update with `rustup update --force-non-host stable-x86_64-unknown-linux-gnu`
assertion failed [result.value != EEXIST]: VmTracker attempted to allocate existing mapping
(ThreadContextVm.cpp:47 mmap)
0024:err:environ:run_wineboot failed to start wineboot c00000e5
0024:err:module:relocate_ntdll ntdll could not be mapped at preferred address (0x7f340000), expect trouble
wine: could not load kernel32.dll, status c0000135

Answer 2 · 2023-11-18T19:58:26.000Z

updated to wine 8.0.2, same error message

Answer 3 · 2023-12-09T01:31:47.000Z

Hi @Emilgardis! I ran into this exact problem and my problem output matched the one in this issue. After updating cross to main & trying cross run --target x86_64-pc-windows-gnu again. I got the following error wine: '/tmp/wine' is not owned by you.

It seems like the permissions aren't setup correctly on ghcr.io/cross-rs/x86_64-pc-windows-gnu image. I did some extra digging and ran docker run --platform linux/amd64 --rm -t -i ghcr.io/cross-rs/x86_64-pc-windows-gnu:main bash and then ls -all /tmp/wine. It gives,

drwxrwxrwx  2 root root    0 Dec  9 01:34 .wine-0
drwxrwxrwx  2 root root    0 Dec  9 01:34 home
drwxrwxrwx  4 root root 4096 Dec  9 01:34 wine

However, running cross run --target x86_64-pc-windows-gnu -vvv gives the folllowing string /usr/bin/docker run --userns host ... -e 'USER=ayush' -e ... --rm --user 1000:1000 ... (... = i've left out the env vars since they were long!). I feel it's trying to run cargo under my machine username but wine is owned by root. If this is the case any ideas on how I can go about working around it until it's fixed. Thank you for working on it.

Answer 4 · 2023-12-11T03:49:17.000Z

Update! Turns out it wasn't really an image issue but an issue of how my docker files were stored. The docker daemon data-root directory wasn't owned by me. I replaced it with another location (ext4 partition new /docker folder) & restarted docker. The error does not occur now and I think I've resolved it. Thank you : )

Answer 5 · 2023-12-11T07:08:06.000Z

Ah perfect @is-it-ayush !

I suppose cross test doesnt work though?

Answer 6 · 2023-12-11T07:20:01.000Z

I suppose cross test doesnt work though?

That's true @Emilgardis! It does not work since the target defaults to ghcr.io/cross-rs/x86_64-unknown-linux-gnu & rust would not compile there since I used windows specific crates.

ps: Just wanted to thank you for this project. It helps a ton with cross compilation. Have an awesome day Emil!

Answer 7 · 2023-12-11T11:49:51.000Z

sorry, I should've specified, cross test --target x86_64-pc-windows-gnu shouldn't work under qemu emulation still because wine doesn't work correctly there

Answer 8 · 2023-12-11T14:04:18.000Z

Just ran cross test --target x86_64-pc-widnows-gnu Emil! It doesn't crash and runs tests successfully but I do get strange output when running it. Here's an example!

Running unittests src/main.rs (/target/x86_64-pc-windows-gnu/debug/deps/hello-world-80kcf46d9b0d8de5.exe)

0084:fixme:hid:handle_IRP_MN_QUERY_ID Unhandled type 00000005
0050:err:winediag:nodrv_CreateWindow Application tried to create a window, but no driver could be loaded.
0050:err:winediag:nodrv_CreateWindow L"The explorer process failed to start."
0050:err:systray:initialize_systray Could not create tray window
0084:fixme:hid:handle_IRP_MN_QUERY_ID Unhandled type 00000005
0084:fixme:hid:handle_IRP_MN_QUERY_ID Unhandled type 00000005
0084:fixme:hid:handle_IRP_MN_QUERY_ID Unhandled type 00000005
010c:err:winediag:ntlm_check_version ntlm_auth was not found. Make sure that ntlm_auth >= 3.0.25 is in your path. Usually, you can find it in the winbind package of your distribution.
010c:err:ntlm:ntlm_LsaApInitializePackage no NTLM support, expect problems

runing <x> tests
# ... test runs
test result: ok. <x> passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.01s

Answer 9 · 2023-12-11T15:59:15.000Z

are you on a aarch64/arm64 host? @is-it-ayush

Answer 10 · 2023-12-12T04:04:05.000Z

are you on a aarch64/arm64 host? @is-it-ayush

I'm on amd64 (running debian 12) host @Emilgardis!

Answer 11 · 2023-12-12T06:51:45.000Z

I see, this issue is specifically for hosts where emulation would be used to run x86_64!

Answer 12 · 2023-12-12T09:57:25.000Z

I see, this issue is specifically for hosts where emulation would be used to run x86_64!

Makes sense!! I think it's more of a wine issue than a cross issue. 😅