cross
cross copied to clipboard
cross-rs
windows-gnu target can't be emulated arm64 qemu via wine
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 https://github.com/cross-rs/cross/issues/1371#issuecomment-1817579558
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
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.
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 : )
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!
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
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
are you on a aarch64/arm64 host? @is-it-ayush
I'm on amd64 (running debian 12) host @Emilgardis!
I see, this issue is specifically for hosts where emulation would be used to run x86_64!
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. 😅