Build fails on Windows with errors in time.rs

[dixonary]

When attempting to build on Windows, a number of error messages are thrown that relate to the use of c_ulong. This is because on Windows, ulong is taken to be u32, while on Linux it is u64 (the type expected by many of these time operations).

The error log is attached:

iced-hs-0.0.3.0-87c47d9b19ab5323312107a3667c6a028691252f - Copy.log

[dixonary]

As a side note, when I "fixed" these errors directly using the suggestions from the compiler, compilation failed at the linker stage, so I do not expect that this is the only blocker to successful Windows compilation.

[ibaryshnikov]

Hey @dixonary, thank you for reporting this! Already on it. Can reproduce both issues. Fixing the ffi types is pretty straightforward, but the linking problem is more complex. To narrow it down, there's the same issue with https://github.com/ibaryshnikov/future-hs, so it's just a general Haskell + Rust story about static linking.

[ibaryshnikov]

I've been researching this for a few days and here are some details

My setup is rustc 1.85 target x86_64-pc-windows-msvc, and ghc 9.4.8 target mingw.
The first error when I tried to compile was

ld.lld: error: undefined symbol: _fltused
>>> referenced by future_hs.lib(core-745ff350a54e4299.core.13dd8dac7b8322e0-cgu.0.rcgu.o)
>>> referenced by future_hs.lib(tokio-edb924c05250f650.tokio.db160f5b6d7b12c0-cgu.07.rcgu.o)
>>> referenced by future_hs.lib(tokio-edb924c05250f650.tokio.db160f5b6d7b12c0-cgu.08.rcgu.o)

ld.lld: error: undefined symbol: const type_info::`vftable'
>>> referenced by future_hs.lib(tokio-edb924c05250f650.tokio.db160f5b6d7b12c0-cgu.15.rcgu.o):(__rust_panic_type_info)
>>> referenced by future_hs.lib(std-99a5467416e27682.std.791127b64b61979d-cgu.0.rcgu.o)
>>> referenced by future_hs.lib(tokio-edb924c05250f650.tokio.db160f5b6d7b12c0-cgu.13.rcgu.o)
>>> referenced 1 more times

ld.lld: error: undefined symbol: __chkstk
>>> referenced by /rustc/4d91de4e48198da2e33413efdcd9cd2cc0c46688/library\std\src\sys\[backtrace.rs:148](http://backtrace.rs:148/)
>>>               future_hs.lib(std-99a5467416e27682.std.791127b64b61979d-cgu.0.rcgu.o):(std::sys::backtrace::__rust_begin_short_backtrace::h990de8d7c811babb)
>>> referenced by /rustc/4d91de4e48198da2e33413efdcd9cd2cc0c46688/library\std\src\sys\pal\windows\[fs.rs:1399](http://fs.rs:1399/)
>>>               future_hs.lib(std-99a5467416e27682.std.791127b64b61979d-cgu.0.rcgu.o):(std::sys::pal::windows::fs::readlink::hcbe8456b355ce463)
>>> referenced by /rustc/4d91de4e48198da2e33413efdcd9cd2cc0c46688/library\std\src\sys\pal\windows\[fs.rs:1612](http://fs.rs:1612/)
>>>               future_hs.lib(std-99a5467416e27682.std.791127b64b61979d-cgu.0.rcgu.o):(std::sys::pal::windows::fs::junction_point::h24447250e1738e30)
>>> referenced 8 more times
clang: error: linker command failed with exit code 1 (use -v to see invocation)
ghc-9.4.8.exe: `clang.exe' failed in phase `Linker'. (Exit code: 1)

Alright, we can find what libraries Rust wants to link to with RUSTFLAGS="--print native-static-libs" cargo build. This prints a few system libraries including msvcrt. Next, I tried passing it to the linker as
'C:\Program Files\Microsoft Visual Studio\2022\Community\VC\Tools\MSVC\14.35.32215\lib\x64\msvcrt.lib'
and it raised a number of duplicate declaration errors. Running ghc with -v shows that it uses -lmingw32. So that's where duplicate symbols come from.

As far as I understand linking with both msvcrt and mingw is not a great idea. Currently ghc supports only mingw target.
So the next possible solution is to try dynamic linking.

[ibaryshnikov]

After a few days of back and forth it looks like there's some work that needs to be done in GHC itself to support UCRT on Windows.