December 2015 - ghc-tickets

[GHC] #10417: Rule matching not "seeing through" floating and type lambda (and maybe cast)
by GHC 15 Sep '16

15 Sep '16

#10417: Rule matching not "seeing through" floating and type lambda (and maybe cast) -------------------------------------+------------------------------------- Reporter: duncan | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- The nub of the problem looks like this. We have a RULE: {{{#!hs {-# RULES "Sequence/Sequence" forall a b c. Sequence (Sequence a b) c = Sequence a (Sequence b c) #-} }}} and some core code that looks like: {{{#!hs failing_example = \ @ s_azo -> Sequence ((failing_example3) `cast` ...) (...) failing_example3 = \ @ s_azo -> Sequence (...) (...) }}} We would hope that the rule would match here but clearly it does not. There's obviously a few things in the way of a straightforward match: 1. the key subterm is floated out 2. there's a `\ @ ->` type lambda in the way in the subterm 3. there's a `cast` in the way in the subterm It appears that the problem is not the cast but the combination of 1 & 2. A reduced example shows the problem occurs with just the first two. That said, the real code would also rely on it working with the `cast`. ---- The rest of this is the code needed to construct the example. The code is also attached to the ticket. {{{#!hs {-# LANGUAGE GADTs, RankNTypes, TypeOperators, ScopedTypeVariables, TypeFamilies, KindSignatures, DataKinds, UndecidableInstances #-} module RulesExample (working_example2) where import Prelude hiding (pure, (<*>)) data Decoder s s' where -- explicit encoding of sequencing Done :: Decoder s s Sequence :: Decoder a b -> Decoder b c -> Decoder a c -- primitive operation in "chained" style ConsumeWord :: Decoder (Word :*: s) s' -> Decoder s s' AlterStack :: (a -> b) -> Decoder b s' -> Decoder a s' data a :*: b = a :*: b infixr 5 :*: }}} We compose actions using the explicit encoding of sequencing {{{#!hs a >>> b = Sequence a b }}} Aside: in the real thing we go via the category class: instance Category Decoder where id = Done a . b = Sequence b a {-# INLINE (.) #-} the Category module defines >>> as flip (.) Now our primitives are in the chained style, and we turn them into the explicit sequencing style by chaining them with Done: {{{#!hs consumeWord :: Decoder s (Word :*: s) consumeWord = ConsumeWord Done alter :: (a -> b) -> Decoder a b alter f = AlterStack f Done }}} example of explicit sequencing: {{{ consumeWord >>> consumeWord >>> ... }}} but naively this will give us things like: {{{ ConsumeWord Done `Sequence` ConsumeWord Done `Sequence` ... }}} and we can interpret this much faster if it's in the "chained" style {{{ ConsumeWord (ConsumeWord (... ) ) }}} Aside: there are good reasons not to just try and construct this chained style in the first place. We can't do it everywhere, and where it would fail we would get bad code. Rather we want to start with something ok and optimise it locally. So, we use RULES to reassociate things and eliminate the Sequence and Done where possible: {{{#!hs {-# RULES "Sequence/Done" forall sa. Sequence Done sa = sa #-} {-# RULES "Sequence/Sequence" forall a b c. Sequence (Sequence a b) c = Sequence a (Sequence b c) #-} {-# RULES "Sequence/ConsumeWord" forall sa sa'. Sequence (ConsumeWord sa) sa' = ConsumeWord (Sequence sa sa') #-} {-# RULES "Sequence/AlterStack" forall f sa sa'. Sequence (AlterStack f sa) sa' = AlterStack f (Sequence sa sa') #-} }}} Now for starters, ghc produces warnings for all three RULES like: {{{ Rule "Sequence/Done" may never fire because ‘RulesExample.Sequence’ might inline first Probable fix: add an INLINE[n] or NOINLINE[n] pragma on ‘RulesExample.Sequence’ }}} but it's currently syntactically invalid to write such a pragma: {{{ {-# INLINE [0] Done #-} {-# INLINE [0] Sequence #-} }}} and also, the warning isn't wholly correct, the rule can fire: {{{#!hs working_example = consumeWord >>> consumeWord >>> alter (\(a :*: b :*: s) -> (a,b) :*: s) }}} actually, this isn't yet quite enough because we cannot persuade ghc to inline consumeWord, because it's just a static composition of constructors, not even if we hit it with the INLINE pragma: {{{#!hs {-# INLINE consumeWord #-} }}} we have to resort to the bigger hammer of an inline rule: {{{#!hs {-# RULES "inline consumeWord" consumeWord = ConsumeWord Done #-} }}} now this is good, we get exactly the core that we want: {{{ $WDone = \ @ s_anC -> Done @~ <s_anC>_N working_example3 = \ @ b_aw2 ds_dAY -> case ds_dAY of _ { :*: a_aoc ds1_dAZ -> case ds1_dAZ of _ { :*: b1_aod s_aoe -> :*: (a_aoc, b1_aod) s_aoe } } working_example2 = \ @ b_aw2 -> AlterStack (working_example3) ($WDone) working_example1 = \ @ b_aw2 -> ConsumeWord (working_example2) working_example = \ @ b_aw2 -> ConsumeWord (working_example1) }}} This is perfect. Each constructor is statically allocated and refers to the next one in the chain. This allows the interpreter to walk over this without triggering any allocation, and the chain style means that in the usual case it doesn't have to do control flow call/return work for the Sequence/Done. Note already that we may have an issue with rule matching on Done, since it does get changed later into $WDone. So it could actually be useful to be able to write: {{{ {-# INLINE [0] Done #-} }}} Ok, so, what doesn't work... Floating things out is not itself a problem, this still works fine, the rules fire. So apparently the `\ @ b_aw2 -> ` type abstraction isn't a problem for the rule matching. {{{#!hs second_example = consumeWord >>> part2 part2 = consumeWord >>> part3 part3 = alter (\(a :*: b :*: s) -> (a,b) :*: s) }}} However the following fails to work. This example is actually extracted from the core of a real example that doesn't work. {{{#!hs artificial_example = Sequence failing_example3 failing_example1 where failing_example3 = Sequence failing_example5 failing_example4 failing_example5 = Sequence Done failing_example6 failing_example6 = ConsumeWord Done failing_example4 = ConsumeWord Done failing_example1 = AlterStack failing_example2 Done failing_example2 (a :*: b :*: s) = (a,b) :*: s }}} here's a specific example of a rule not matching: {{{ ailing_example3 = \ @ a_ax3 -> Sequence (failing_example4) (failing_example4) failing_example4 = \ @ s_awp -> ConsumeWord ($WDone) }}} This should match the rule {{{ Sequence (ConsumeWord sa) sa' = ConsumeWord (Sequence sa sa') }}} but apparently does not. The combo of the floating out and the type lambda seem to get in the way. Note that in this example ghc has also CSE'd the failing_example4 with failing_example5 and so failing_example4 is used twice. But if that's the problem here, there also equivalent instances of the Sequence/Sequence rule not matching. Also, ConsumeWord is certainly CONLIKE so we'd hope even if ghc had already CSEd that it'd allow the duplication for the rule matching. In fact looking at the simpl iterations I think the rule would have gotten a chance to fire before the CSE occured. In the real example that the above was extracted from we also have `cast`s in the way. Unfortunately we need more infrastructure to illustrate the full example. I don't think the details of this infrastructure is important, except that it ends up giving us `cast` in the core. We're building an abstraction on top of Decoder to let us use Applicative style. {{{#!hs data Fun a = Id | Cons a | O (Fun a) (Fun a) -- this requires UndecidableInstances type family Apply (f :: Fun *) (a :: *) :: * type instance Apply Id a = a type instance Apply (Cons x) a = x :*: a type instance Apply (O f g) a = Apply f (Apply g a) }}} we pair up stack changes and their inverses {{{#!hs data DecoderA0 s (f :: Fun *) a = DecoderA0 (Decoder s (Apply f s)) -- change the stack from s -> f s (Apply f s -> (s, a)) -- change stack back from f s -> s {-# INLINE pure0 #-} pure0 :: forall a s. a -> DecoderA0 s Id a pure0 a = DecoderA0 Done (\s -> (s, a)) {-# INLINE app0 #-} app0 :: DecoderA0 s f (a -> b) -> DecoderA0 (Apply f s) g a -> DecoderA0 s (g `O` f) b app0 (DecoderA0 d f) (DecoderA0 d' x) = DecoderA0 (d >>> d') appStack where -- just flipped <*> for state monad appStack = \s -> case x s of (s', x') -> case f s' of (s'', f') -> (s'', f' x') {-# INLINE close0 #-} close0 :: forall s f a. DecoderA0 s f a -> Decoder s (a :*: s) close0 (DecoderA0 d se) = d >>> alter se' where se' :: Apply f s -> (a :*: s) se' s = case se s of (s', a) -> a :*: s' }}} now we can abstract over the stack change, because it always takes us back to the same initial stack state {{{#!hs data DecoderA a where DecoderA :: (forall s. DecoderA0 s f a) -> DecoderA a }}} in the real thing we use Functor and Applicative instances, but we only need bits {{{#!hs pure a = DecoderA (pure0 a) DecoderA f <*> DecoderA x = DecoderA (app0 f x) infixl 4 <*> }}} now conversions functions: {{{#!hs {-# INLINE embedDecoderA #-} embedDecoderA :: DecoderA a -> Decoder s (a :*: s) embedDecoderA (DecoderA ap) = close0 ap {-# INLINE[1] embedDecoder #-} embedDecoder :: forall a. (forall s. Decoder s (a :*: s)) -> DecoderA a embedDecoder dec = DecoderA popResultAp where popResultAp :: DecoderA0 s (Cons a) a popResultAp = DecoderA0 dec (\(a :*: s) -> (s, a)) }}} ok, we can finally build our example... {{{#!hs failing_example = embedDecoderA $ pure (,) <*> embedDecoder consumeWord <*> embedDecoder consumeWord }}} So all the applicative stuff gets inlined away, but we end up with this core: {{{ $WDone = \ @ s_anC -> Done @~ <s_anC>_N failing_example6 = \ @ s_azo -> ConsumeWord ($WDone) failing_example4 = \ @ s_azo -> ConsumeWord ($WDone) failing_example5 = \ @ s_azo -> Sequence (($WDone) `cast` ...) ((failing_example6) `cast` ...) failing_example3 = \ @ s_azo -> Sequence ((failing_example5) `cast` ...) ((failing_example4) `cast` ...) failing_example2 = \ @ s_azo s1_aox -> case s1_aox `cast` ... of _ { :*: a_aoH s2_aoI -> case s2_aoI `cast` ... of _ { :*: a1_Xpa s3_Xpc -> :*: (a1_Xpa, a_aoH) (s3_Xpc `cast` ...) } } failing_example1 = \ @ s_azo -> AlterStack (failing_example2) ($WDone) failing_example = \ @ s_azo -> Sequence ((failing_example3) `cast` ...) (failing_example1) }}} We have two examples of RULES not mathing where we would have hoped. Firstly, we have: {{{ Sequence (($WDone) `cast` ...) (...) }}} We would of course hope that the rule Sequence Done sa = sa would match here It's unclear if this is due to the `$WDone` or the `cast`. Certainly the conversion from Done to `$WDone` can be worked around by using a function {{{ {-# INLINE [0] done #-} done = Done }}} and changing the code and rules to use that. So the main problem is the one mentioned at the top of the ticket: {{{ failing_example = \ @ s_azo -> Sequence ((failing_example3) `cast` ...) (...) failing_example3 = \ @ s_azo -> Sequence (...) (...) }}} We would hope that this rule would match {{{ Sequence (Sequence a b) c = Sequence a (Sequence b c) }}} So this is the same issue as in the artificial example but now additionally there's a `cast` in the way in the subterm. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10417> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #9089: Local .ghci_history
by GHC 10 Sep '16

10 Sep '16

#9089: Local .ghci_history ------------------------------------+------------------------------------- Reporter: jcristovao | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.8.2 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- Hello, It would be nice to allow a local .ghci_history to be used (when available) instead of the global .ghc/ghci_history. This would be similar in behaviour to the .ghci rules: http://www.haskell.org/ghc/docs/7.8.2/html/users_guide/ghci-dot-files.html And I believe this should not be too complicated to do (I can even try it myself, if there is interest). -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9089> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 15

[GHC] #9880: ghc crashes on th splices in instance context
by GHC 07 Sep '16

07 Sep '16

#9880: ghc crashes on th splices in instance context -------------------------------------+------------------------------------- Reporter: Philonous | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Given Class.hs: {{{#!hs module Class where class Foo a where bar :: a -> Int }}} TH.hs {{{#!hs {-# LANGUAGE TemplateHaskell #-} module TH where import Class import Language.Haskell.TH mkFun :: Q [Dec] mkFun = return [FunD 'bar [Clause [WildP] (NormalB (LitE (IntegerL 0))) []]] }}} and Instance.hs {{{#!hs {-# LANGUAGE TemplateHaskell #-} module Instance where import TH import Class instance Foo Bool where $(mkFun) }}} compiling the project crashes ghc with {{{ #ghc --make Instance.hs [2 of 3] Compiling TH ( TH.hs, TH.o ) [3 of 3] Compiling Instance ( Instance.hs, Instance.o ) ghc: panic! (the 'impossible' happened) (GHC version 7.8.3 for x86_64-unknown-linux): cvBindsAndSigs $[splice{v}]mkFun{v} Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9880> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

[GHC] #10062: Codegen on sequential FFI calls is not very good
by GHC 05 Sep '16

05 Sep '16

#10062: Codegen on sequential FFI calls is not very good -------------------------------------+------------------------------------- Reporter: chadaustin | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 (CodeGen) | Operating System: Unknown/Multiple Keywords: | Type of failure: Runtime Architecture: | performance bug Unknown/Multiple | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- I'm writing a library for efficiently building up a byte buffer. The fastest approach I've found is via FFI, with restricted effects like ST. It's over twice as fast as ByteString Builder. Consider this example API usage: https://github.com/chadaustin/buffer- builder/blob/6bd0a39c56f63ab751faf29f9784ac87d52638be/bench/Bench.hs#L46 It compiles into an instruction sequence containing direct, sequenced FFI calls. For example, the last three calls work out to: addq $8,%rsp movq %rbx,%rdi movq 72(%rsp),%rax movq %rax,%rsi subq $8,%rsp movl $0,%eax call bw_append_bsz addq $8,%rsp movq %rbx,%rdi movl $35,%esi subq $8,%rsp movl $0,%eax call bw_append_byte addq $8,%rsp movq %rbx,%rdi movq 64(%rsp),%rax movq %rax,%rsi subq $8,%rsp movl $0,%eax call bw_append_bsz I don't know why rsp is being changed so much. I also can't explain the assignment to eax before the call. (It should also be xorl eax,eax, I would think.) To my reading, the above instruction sequence could be reduced to: movq %rbx,%rdi movq 64(%rsp),%rsi call bw_append_bsz movq %rbx,%rdi movl $35,%esi call bw_append_byte movq %rbx,%rdi movq 56(%rsp),%rsi call bw_append_bsz To reproduce, check out git@github.com:chadaustin/buffer-builder.git at revision 6bd0a39c56f63ab751faf29f9784ac87d52638be cabal configure --enable-benchmarks cabal bench And then look at the ./dist/build/bench/bench-tmp/bench/Bench.dump-asm file. This is specifically on OS X 64-bit with GHC 7.8.3, but I saw similar code generation on GHC 7.6 on Linux 64-bit. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10062> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 8

[GHC] #10858: Smaller generated instances
by GHC 05 Sep '16

05 Sep '16

#10858: Smaller generated instances -------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- With very large modules with lots of deriving code, GHC spends quite some time compiling. I believe that we can improve things by reducing the size of the generated code. (More in the comments) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10858> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 21

[GHC] #10161: GHC does not relink if a library's code changed
by GHC 03 Sep '16

03 Sep '16

#10161: GHC does not relink if a library's code changed -------------------------------------+------------------------------------- Reporter: nh2 | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.4 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Test case for reproducing: https://github.com/nh2/ghc-relinking-avoidance- bug/ ---- {{{myexe}}} is an executable that depends on {{{mylib}}}, whose {{{myfun = putStrLn "output 1"}}}. If we install {{{mylib}}}, compile {{{myexe}}}, then change mylib's code to {{{myfun = putStrLn "output 2"}}}, re-install it, and then compile {{{myexe}}}, then GHC does not notice that the library code changed. It avoids re-linking myexe, with the result that the program prints {{{output 1}}} when you told it to compile against code that prints {{{output 2}}}. ---- Note that I had to use {{{NOINLINE myfun}}} to trigger the bug, since otherwise {{{myfun}}}'s code would have ended up in the interface file, thus changing the package ID, which naturally forces GHC to relink (even re-compile). With the {{{NOINLINE}}}, the package IDs of the two different versions of {{{myfun}}} are completely identical. I think that is correct, since the package ID only hashes the API and ABI, not the actual implementation, right? How does GHC decide when to relink? I think in the present case, it doesn't notice that the object/archive file of the library changed. Does it check that somehow? Just looking at API and API can't be enough to make a decision for linking. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10161> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #10923: GHC should recompile if flags change
by GHC 02 Sep '16

02 Sep '16

#10923: GHC should recompile if flags change -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: bug | Status: new Priority: low | Milestone: Component: Compiler | Version: 7.10.2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | -------------------------------------+------------------------------------- Example: {{{ ezyang@sabre:~$ rm B.hi ezyang@sabre:~$ Dev/ghc-7.10.2/usr/bin/ghc -c B.hs ezyang@sabre:~$ Dev/ghc-7.10.2/usr/bin/ghc -c B.hs -O compilation IS NOT required }}} Pretty minor, but would be nice to have fixed. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10923> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 9

[GHC] #10963: Beginner-targeted language extension
by GHC 29 Aug '16

29 Aug '16

#10963: Beginner-targeted language extension -------------------------------------+------------------------------------- Reporter: kanetw | Owner: Type: feature | Status: new request | Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- FMP significantly complicated type signatures such as `length :: Foldable t => t a -> Int`, which makes teaching Haskell more difficult. I propose a language extension `-XBeginner` which instructs GHC(i) to specialize `Foldable` and `Traversable` to `[]` when possible and in case of an ambiguous instance, default those to `[]`. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10963> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 25

[GHC] #10547: feature request: expanding type synonyms in error messages
by GHC 26 Aug '16

26 Aug '16

#10547: feature request: expanding type synonyms in error messages -------------------------------------+------------------------------------- Reporter: osa1 | Owner: osa1 Type: feature | Status: new request | Milestone: 7.12.1 Priority: low | Version: Component: Compiler | Operating System: Unknown/Multiple (Type checker) | Type of failure: None/Unknown Keywords: | Blocked By: Architecture: | Related Tickets: Unknown/Multiple | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Type errors sometimes becoming confusing because of synonyms, for example, expected type and found type sometimes use different synonyms or sometimes only one of them use a synonym etc. We discussed this in the mailing list: https://mail.haskell.org/pipermail /ghc-devs/2015-June/009247.html And also moved it to the Wiki to collect examples: https://wiki.haskell.org/Expanding_type_synonyms_in_error_messages_proposal I'm currently working on a patch, I made some progress and I'll hopefully submit something for reviews in a couple of days. This ticket is for further discussions and keep track of the progress. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10547> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 23

[GHC] #11072: Runtime linker doesn't search for DLLs referenced in import libraries on Windows
by GHC 25 Aug '16

25 Aug '16

#11072: Runtime linker doesn't search for DLLs referenced in import libraries on Windows -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Phyx- Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.10.2-rc2 (Linking) | Keywords: | Operating System: Windows Architecture: | Type of failure: Runtime crash Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- (This is adapted from the comments [https://github.com/bos/text- icu/issues/12#issuecomment-154452774 here].) On Windows, the GHC runtime linker only searches for DLLs that have the same names as the import libraries passed to `-l`. This can sometimes create problems, since a library name could be different from the DLL it needs. `text-icu` provides an example of this, since it needs the extra libraries `icuuc`, `icudt`, and `icuin`. However, if you download the [http://site .icu-project.org/download/56#TOC-ICU4C-Download official ICU 56 binaries], they are distributed with DLLs named `icuuc56.dll`, `icudt56.dll`, and `icuin56.dll`, rather than `icuuc.dll`, `icudt.dll`, and `icuin.dll`. This doesn't create any trouble for the linker at compile-time. In fact, if you compile this program {{{#!hs -- TextICU.hs import Data.Text.ICU.Break main = print Kana }}} with `ghc TextICU.hs` and then run `cygcheck ./TextICU.hs` without having the ICU4C `bin64` folder in your `PATH`, it ''appears'' to search for the right DLLs: {{{ $ cygcheck ./TextICU.hs ... cygcheck: track_down: could not find icuin56.dll cygcheck: track_down: could not find icuuc56.dll }}} But actually running the code reveals a different story: {{{ $ runghc TextICU.hs TextICU.hs: icuuc: The specified module could not be found. TextICU.hs: <command line>: can't load .so/.DLL for: icuuc.dll (addDLL: could not load DLL) }}} This demonstrates that the runtime linker behaves differently; it is dependent on what the linked libraries' names are. To confirm this, you can recompile `text-icu` with the following changes to `text-icu.cabal`: {{{ extra-libraries: icuuc56 if os(mingw32) extra-libraries: icuin56 icudt56 }}} Also make symlinks named `icuuc56.lib`, `icuin56.lib`, and `icudt56.lib` that refer to `icuuc.lib`, `icuin.lib`, and `licudt.lib`, respectively, in the ICU4C `lib64` directory. Now `cygcheck` and `ghc` agree on which DLLs to use: {{{ $ ghc TextICU.hs $ cygcheck ./TextICU.exe ... cygcheck: track_down: could not find icuin56.dll cygcheck: track_down: could not find icuuc56.dll $ runghc TextICU.hs TextICU.hs: icuuc56: The specified module could not be found. TextICU.hs: <command line>: can't load .so/.DLL for: icuuc56.dll (addDLL: could not load DLL) }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11072> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 25