What's the current state of cross-compilation from Linux -> Windows with (i686|x86_64)-pc-windows-gnu?

[LunarLambda]

I'm currently trying to somehow build a 32-bit Windows cdylib on Linux (although this should apply to any crate type, not just cdylibs), and after hours of intense rabbitholing through multiple years-old GitHub issues, I wanna compile what I've gathered.

i686-pc-windows-gnu:

1. requires an externally-installed mingw compiler toolchain.
2. will only work if said toolchain uses dw2 exception handling, since that's what Rust expects
3. with few exceptions, most distributions only provide mingw packages which use sjlj exceptions.
4. there were multiple attempts to resolve this, all of them more or less fruitless
5. if you can't easily obtain a dw2 toolchain, you have the following options:
   5.1 use xargo (and thus nightly) to compile std and your code with panic=abort
   5.2 use cross, which has a docker image that will build a dw2 toolchain for you, incurring significant build time overhead.

x86_64-pc-windows-gnu:

1. still requires an externally-installed mingw toolchain.
2. sort of just works? most distros provide packages that use SEH, rust expects SEH, all is well in the world^{[citation extremely needed]}
   (unfortunately, this does not help me, as I don't think 32-bit programs can load 64-bit libraries.)

questions I couldn't answer:

1. is there any (current) work happening to improve the situation around i686-pc-windows-gnu, or is it officially 'abandon all hope, ye who enter here' territory?
2. what is the situation regarding threads? mingw comes in posix and win32-threads flavours, and this has in the past been an additional source of problems, I'm not sure if this has been fixed? ([windows] Add testscase for self-contained executables and fix pthread linking #71023)

update 21:43 2020-11-30: The docker image cross provides seems to have worked. I could build the cdylib, load it, and call a function in it. this is still far from ideal, as the docker image took significant amounts of time to prepare, and consumes significant amounts of disk space..

[mati865]

with few exceptions, most distributions only provide mingw packages which use sjlj exceptions.

Most of the common distributions already use Dwarf-2 (Arch Linux, Fedora) or are in progress to switch (Debian) soon.

[LunarLambda]

Arch does not package DWARF-2 compilers, to my knowledge Which is why I had to use `cross`, and what led me to open this issue attempting to build a cdylib containing only #[no_mangle] pub unsafe extern fn return_one() -> i32 { 1 } with `cargo build --target=i686-pc-windows-gnu` on an up-to-date Arch system and Rust 1.46 stable fails with ~10K of linker errors about undefined references to `Unwind_Resume_`, and, from what I could gather, this was a known problem with mingw packages built with SJLJ unwinding.

…

On Tue, 1 Dec 2020, 23:36 Mateusz Mikuła, ***@***.***> wrote: with few exceptions, most distributions only provide mingw packages which use sjlj exceptions. Most of the common distributions already use Dwarf-2 (Arch Linux, Fedora) or are in progress to switch (Debian <https://salsa.debian.org/mingw-w64-team/gcc-mingw-w64/-/commit/8da432fefb792fbe2f9fec2f15278d02e86e6281>) soon. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#79577 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AJI55IW7MSZHKDYNVVHEY73SSVVXNANCNFSM4UIB6SSQ> .

[mati865]

I'll try on my Arch later today but GCC is definitely built with Dwarf-2: https://github.com/archlinux/svntogit-community/blob/863707d772cb9d3b8d67c060dd7b48a20fa7b33a/trunk/PKGBUILD#L54

[LunarLambda]

related issue:

#79609

[LunarLambda]

I'll try on my Arch later today but GCC is definitely built with Dwarf-2: https://github.com/archlinux/svntogit-community/blob/863707d772cb9d3b8d67c060dd7b48a20fa7b33a/trunk/PKGBUILD#L54

Thank you for pointing me towards the PKGBUILD.
I decided to investigate and realised my compiler package outdated due to what looks like an improper package renaming. [Update: See below]

After this re-install, it works fine. Closing this.

POSTMORTEM: The mingw-w64-gcc was moved from the Arch package repository to the AUR in 2018. This means at the time I installed it, the compilers did not yet use DWARF2, and I did not receive updates through pacman -Syu.

In August of this year, the package was added back to the regular repositories.