QuasiQuotes breaks building text-icu on Windows

[daniel-chambers]

General summary/comments

The text-icu package does not build on Windows when quasiquotes is turned on. I'm not sure what's causing this issue, whether it is a Stack issue or a GHC issue, but I thought I'd start here and maybe someone with more knowledge might know. :)

This does appear to be a Windows-specific issue. I tried to reproduce on Ubuntu (via Windows Subsystem for Linux) and was unable to reproduce the issue there.

Steps to reproduce

OS: Windows 10 x64 1803

1. Create a new project: stack --resolver lts-12.19 new TextIcuRepro
2. Run stack exec -- pacman -Sy mingw64/mingw-w64-x86_64-icu to install the necessary dependency for text-icu (as suggested here)
3. Add text-icu and raw-strings-qq to TextIcuRepro-exe's dependencies
4. Change Main.hs to this:

{-# LANGUAGE QuasiQuotes #-}

module Main
    ( main
    )
where

import Text.RawString.QQ

multiline :: String
multiline = [r| so broken|]

main :: IO ()
main = pure ()

5. Run stack build

Expected

Successful build

Actual

ghc.EXE: unable to load package `text-icu-0.7.0.1'
ghc.EXE:  | C:\StackRoot\snapshots\a764cace\lib\x86_64-windows-ghc-8.4.4\text-icu-0.7.0.1-7ooZ4yUAwls6Vjo7Y3nmWM\HStext-icu-0.7.0.1-7ooZ4yUAwls6Vjo7Y3nmWM.o: unknown symbol `ucnv_getMaxCharSize_62'

--  While building package TextIcuRepro-0.1.0.0 using:
      C:\StackRoot\setup-exe-cache\x86_64-windows\Cabal-simple_Z6RU0evB_2.2.0.1_ghc-8.4.4.exe --builddir=.stack-work\dist\7d103d30 build lib:TextIcuRepro exe:TextIcuRepro-exe --ghc-options " -ddump-hi -ddump-to-file -fdiagnostics-color=always"
    Process exited with code: ExitFailure 1

If you remove the QuasiQuotes usage from Main.hs then it starts building:

1. Remove QuasiQuotes usage from Main.hs:

module Main
    ( main
    )
where

main :: IO ()
main = pure ()

2. stack build
3. Observe successful build when quasiquotes removed.

I also tried this using some quasiquotes from the odbc package instead of raw-strings-qq to make sure it wasn't that specific package's issue and the same behaviour can be observed.

Gist of the verbose stack build --verbose output: https://gist.github.com/daniel-chambers/03942b0d40a21abb89e848f6adbc94ab

Stack version

Version 1.9.1, Git revision f9d0042c141660e1d38f797e1d426be4a99b2a3c (6168 commits) x86_64 hpack-0.31.0

Method of installation

Official binary, downloaded from stackage.org or fpcomplete's package repository

[dbaynard]

Related:

• Pacman workaround for Windows not working anymore haskell/text-icu#40
• https://stackoverflow.com/questions/45775326/building-haskell-ide-engine-error-unknown-symbol-ucnv-getmaxcharsize-58
• Stack install failing on windows with unknown symbol ucnv_getMaxCharSize_58'` haskell/lsp#56

The latter mentions haskell/lsp#41 as a workaround.

That said, you might be better trying haskell/text-icu#36 instead of hackage's text-icu.

I'm going to label as upstream, and remove the bug designation for now. If that doesn't fix it (and you can't reproduce with cabal-install) I'll add it back.

[daniel-chambers]

Thanks; I'll try the workarounds out and report back.

[daniel-chambers]

I can confirm that the haskell/text-icu#36 PR (as yet unmerged) fixes the problem. This isn't a Stack problem then, but a problem with text-icu itself. Sorry for reporting in the wrong spot and thanks for the help. 😃

For others looking for the solution, I added the following to my stack.yaml extra-deps to use that PR's code instead of the package in the snapshot.

extra-deps:
- git: https://github.com/LukaHorvat/text-icu.git # Use a patched version of text-icu from https://github.com/bos/text-icu/pull/36
  commit: 9672dc725028b0b92e51ca6f69a78593978be78b