# Looking for help with build on Windows

**URL:** <https://discourse.haskell.org/t/looking-for-help-with-build-on-windows/12227>\
**Category:** Uncategorized\
**Created:** [June 2, 2025, 4:53pm UTC](https://discourse.haskell.org/t/looking-for-help-with-build-on-windows/12227 "2025-06-02T16:53:54Z")\
**Posts on this page:** 5\
**Page:** 1

<div class="post-metadata">

**Author:** ![reki](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.haskell.org/reki/32/5023_2.png) [@reki](https://discourse.haskell.org/u/reki)\
**Post date:** [June 2, 2025, 4:53pm UTC](https://discourse.haskell.org/t/looking-for-help-with-build-on-windows/12227/1 "2025-06-02T16:53:54Z")

</div>

There’s an error when I try to link a static library produced by Rust with a Haskell program on Windows (I think it’s version 11 already, will provide more precise details as needed). It’s either `symbols not found` or `duplicate symbols`. As far as I was able to research the problem, it might be related to `UCRT` support in Haskell. Rust added `UCRT` support quite awhile ago. And as I read in the issues on GHC gitlab, `UCRT` is supported by GHC too. For example, here:

> **[\#25378: Support MSYS2/UCRT64 and others · Issues · Glasgow Haskell Compiler /...](https://gitlab.haskell.org/ghc/ghc/-/issues/25378)**
>
> Summary It would be awesome to support other MSYS toolchains like UCRT64 and clang64. According to the documentation, GHC still requires...

The issue with more details and some logs is here:

> <https://github.com/ibaryshnikov/iced-hs/issues/19>
>
> 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\](https://github.com/user-attachments/files/18887228/iced-hs-0.0.3.0-87c47d9b19ab5323312107a3667c6a028691252f.-.Copy.log)

And there’s a small repo if you want a quick way to reproduce the build error:

> **[GitHub - ibaryshnikov/future-hs: Future Monad](https://github.com/ibaryshnikov/future-hs)**
>
> Future Monad

Any help is welcome, as this issue seems to be beyond my powers to solve.

---

<div class="post-metadata">

**Author:** ![reki](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.haskell.org/reki/32/5023_2.png) [@reki](https://discourse.haskell.org/u/reki)\
**Post date:** [August 30, 2025, 10:16am UTC](https://discourse.haskell.org/t/looking-for-help-with-build-on-windows/12227/2 "2025-08-30T10:16:29Z")

</div>

To offload the recent topic with release announcement, topping this up. The help is still much appreciated. Some of the ideas we’ve tested so far can be found in the comments for the linked discussion. In case someone wants to test it out, the minimal repo is the same, `future-hs`

> [@GHC 9.14.1-alpha1 released](https://discourse.haskell.org/t/ghc-9-14-1-alpha1-released/12786):
>
> The GHC developers are very pleased to announce the availability of the first alpha prerelease of GHC 9.14.1. Binary distributions, source distributions, and documentation are available at [downloads.haskell.org](https://downloads.haskell.org/ghc/9.14.1-alpha1). GHC 9.14 will bring a number of new features and improvements, including: Significant improvements in specialisation: The SPECIALISE pragma now allows use of type application syntax The SPECIALISE pragma can be used to specialise for expression arguments as well as type argumen…

---

<div class="post-metadata">

**Author:** ![darkxero](https://avatars.discourse-cdn.com/v4/letter/d/f07891/32.png) [@darkxero](https://discourse.haskell.org/u/darkxero)\
**Post date:** [August 30, 2025, 10:02pm UTC](https://discourse.haskell.org/t/looking-for-help-with-build-on-windows/12227/3 "2025-08-30T22:02:11Z")

</div>

The issue is not merely agreeing to link UCRT over msvcrt, the issue is that the Haskell toolchain is MingW (Clang, with libclang\_rt.\*), the Rust toolchain is MSVC, and the Rust GNU toolchain is MingW (GCC, with libgcc).

On another note, I looked again and found: [\*-pc-windows-gnullvm - The rustc book](https://dev-doc.rust-lang.org/beta/rustc/platform-support/pc-windows-gnullvm.html)

Try targeting this one and pointing to the MingW of GHC.

But it says on the page that it doesn’t come with std compiled, you will need to build it with Cargo. Or recompile Rustc with the Haskell toolchain. Or recompile GHC with the Rust (GNU) toolchain.

---

<div class="post-metadata">

**Author:** ![reki](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.haskell.org/reki/32/5023_2.png) [@reki](https://discourse.haskell.org/u/reki)\
**Post date:** [August 30, 2025, 11:08pm UTC](https://discourse.haskell.org/t/looking-for-help-with-build-on-windows/12227/4 "2025-08-30T23:08:56Z")

</div>

This is a step forward! I thought that it’s an issue related to UCRT, but now you helped to clarify it, thank you for this research!

In perfect scenario I’d like to see both compilers use the same toolchain, MSVC in this case. But until that happens, `x86_64-pc-windows-gnullvm` Rust target might be a good option. I’m not sure about std, the platform page says this target has std built. And also:

> The easiest way to obtain these targets is cross-compilation

So it might be possible to build for this target using the default Rust compiler.

And on top of that, I’ve just managed to compile MicroHS, which uses MSVC toolchain. This makes me curious how far can it compile this UI project (iced-hs I mean). Still, having two options is better than having none.

---

<div class="post-metadata">

**Author:** ![reki](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.haskell.org/reki/32/5023_2.png) [@reki](https://discourse.haskell.org/u/reki)\
**Post date:** [August 30, 2025, 11:18pm UTC](https://discourse.haskell.org/t/looking-for-help-with-build-on-windows/12227/5 "2025-08-30T23:18:08Z")

</div>

After you mentioned it, I’ve quickly searched through GHC issues and found this one:

> **[\#17192: Windows without MinGW · Issues · Glasgow Haskell Compiler / GHC · GitLab](https://gitlab.haskell.org/ghc/ghc/-/issues/17192)**
>
> This is a long term, pie-in-the-sky goal, but it would be nice to build binaries without MinGW / MSYS. LLVM's Windows support is now superior, especially when C++...