July 2017 - ghc-tickets

[GHC] #13992: Error message, room for improvement (polykinds)
by GHC 17 Dec '18

17 Dec '18

#13992: Error message, room for improvement (polykinds) -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: PolyKinds | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Something like {{{#!hs -- • No instance for (Show (Compose Proxy Proxy a)) -- arising from the 'deriving' clause of a data type declaration -- Possible fix: -- use a standalone 'deriving instance' declaration, -- so you can specify the instance context yourself -- • When deriving the instance for (Show (FlipProxy a)) {-# Language DerivingStrategies, GeneralizedNewtypeDeriving, PolyKinds, KindSignatures #-} import Data.Functor.Compose import Data.Proxy import Data.Kind newtype FlipProxy a = FlipProxy_ (Compose Proxy Proxy a) deriving newtype Show }}} where the solution is to constraint the kind of `a :: Type`, it would be nice if GHC could reference kind variables. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13992> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #11042: Template Haskell / GHCi does not respect extra-lib-dirs
by GHC 11 Dec '18

11 Dec '18

#11042: Template Haskell / GHCi does not respect extra-lib-dirs -------------------------------------+------------------------------------- Reporter: mboes | Owner: Type: bug | 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: #10458 #5289 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- In particular when compiling on NixOS, but also in many other situations, it is often needed to pass --extra-lib-dirs / --extra-include-dirs to cabal/stack, to help GHC find required system libraries. This works fine for GHC, but not GHCi, and therefore also not Template Haskell code. Minimal example attached. Try it in an environment where libz is not in a standard location, e.g. inside a nix-shell. Note that if you remove the template Haskell splice in Main.hs, the code compiles just fine. This affects GHC 7.10.2, but also HEAD from 2015-08-28, even one including Tamar Christina's 5d841108acef950fed6a5e608ac9b18e7431aa87 commit cherry- picked. I haven't been able to test more recent HEAD, because of unrelated compilation issues. I surmise that a fix to #10458, which currently blocks using HaskellR in GHCi, would also fix this, but I'm not sure. The error message I get is different: {{{ $ stack build --skip-ghc-check --extra-lib- dirs=/nix/store/31w31mc8immhpnmxvcl4l0fvc3i5iwh0-zlib-1.2.8/lib --extra- include- dirs=/nix/store/31w31mc8immhpnmxvcl4l0fvc3i5iwh0-zlib-1.2.8/include b-0.1.0.0: build Preprocessing executable 'b' for b-0.1.0.0... [2 of 2] Compiling Main ( src/Main.hs, .stack- work/dist/x86_64-linux/Cabal-1.23.0.0/build/b/b-tmp/Main.o ) <command line>: can't load .so/.DLL for: libz.so (libz.so: cannot open shared object file: No such file or directory) -- While building package b-0.1.0.0 using: /home/mboes/.stack/setup-exe-cache/setup-Simple- Cabal-1.23.0.0-x86_64-linux-ghc-7.11.20150828 --builddir=.stack- work/dist/x86_64-linux/Cabal-1.23.0.0/ build exe:b --ghc-options " -ddump- hi -ddump-to-file" Process exited with code: ExitFailure 1 }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11042> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 38

[GHC] #13897: Ship check-ppr in bindist and compile during testsuite run
by GHC 11 Dec '18

11 Dec '18

#13897: Ship check-ppr in bindist and compile during testsuite run -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: task | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.0.1 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: -------------------------------------+------------------------------------- Currently `check-ppr` is built during the compiler build and used by the testsuite in the pretty-printer tests. In a source checkout this is fine, however this arrangement blows up in the case of a binary distribution as we don't (and probably shouldn't) ship the `check-ppr` binary in the bindist. I think the most reasonable way to deal with this is to instead ship the `check-ppr` source (perhaps in the testsuite tarball) and build it as a dependency of the testsuite. Ideally we would build the executable once and use it for each of the ppr tests. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13897> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 10

[GHC] #9718: Avoid TidyPgm predicting what CorePrep will do
by GHC 10 Dec '18

10 Dec '18

#9718: Avoid TidyPgm predicting what CorePrep will do -------------------------------------+------------------------------------- Reporter: simonpj | 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: -------------------------------------+------------------------------------- At the moment the `TidyPgm` pass is forced to predict, accurately but unpleasantly, some aspects of what `CorePrep` and `Core2Stg` will do. Reason: * Each `Id` in the interface file records (among other things) the '''arity''' of the `Id`, and whether it has '''CAF references''' * We really only know these two things for sure after `CorePrep`. The conversion from Core to STG makes no structural changes. * However the result of `TidyPgm` (which preceded `CorePrep`) is used to generate the interface file. So it has to predict the arity and CAF-ref status of each `Id`. * This is not good. It restricts what `CorePrep` can do (notably, it must not change the arity of a top-level `Id`), and it leads to unsavoury code (e.g. look at the call to `CorePrep.cvtLitInteger` in `TidyPgm.cafRefsL`. It's also dangerous: an inconsistency could lead to a crash. This is a long-standing problem. My current thought for how to unravel it is this: * `TidyPgm` does not attach arity or CAF-ref info. * Instead, run `CorePrep` after `TidyPgm`, and generate accurate arity and CAF-ref info * Then use that auxiliary mapping during the conversion from tidied program to `ModIface`. I don't think this would be hard. It would mean that the tidied program and the core-prep'd program would have to exist in memory at the same time. An alternative would be to generate the `ModIface` from the tidied program ''sans'' arity and CAF-ref info, and then, after `CorePrep` run over it to add arity and CAF-ref info. (You'd have to do this before generating the fingerprints.) The advantage of this is that the `ModIface` can be a lot smaller than the code for the entire module. A long-standing wart which needs some careful attention. Simon -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9718> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 42

[GHC] #12893: Profiling defeats stream fusion when using vector library
by GHC 09 Dec '18

09 Dec '18

#12893: Profiling defeats stream fusion when using vector library -------------------------------------+------------------------------------- Reporter: newhoggy | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: stream-fusion | Operating System: MacOS X profiling | Architecture: x86_64 | Type of failure: Runtime (amd64) | performance bug Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I have this problem where enabling profiling in Haskell undoes stream fusion and I’d like to do my profiling with stream fusion intact. The following reproduces my problem: {{{ $ git clone git@github.com:haskell-works/hw-tutorial-performance.git $ cd hw-tutorial-performance/ $ stack init $ stack build --executable-profiling $ time $(find .stack-work/dist/ -type f -name hw-tutorial-performance- rwhe) 1e7 5000000.5 real 0m4.432s user 0m3.484s sys 0m0.936s $ rm -rf .stack-work/ $ stack build $ time $(find .stack-work/dist/ -type f -name hw-tutorial-performance- rwhe) 1e7 5000000.5 real 0m0.034s user 0m0.018s sys 0m0.013s With profiling, my program takes over 4 seconds to run. Without profiling, it only takes 0.034 seconds. }}} The problem has nothing to do with stack. {{{ (java-1.8.0 ghc-7.10.3) ✔ ~/wrk/haskell-works/hw-tutorial-performance/hw- tutorial-performance-rwhe [master|✚ 1] 08:12 $ ghc -fforce-recomp --make -O2 -funbox-strict-fields -rtsopts -optc-O2 Main.hs [1 of 1] Compiling Main ( Main.hs, Main.o ) Linking Main ... (java-1.8.0 ghc-7.10.3) ✔ ~/wrk/haskell-works/hw-tutorial-performance/hw- tutorial-performance-rwhe [master|✚ 1] 08:12 $ time ./Main +RTS -sstderr -RTS 1e7 5000000.5 115,888 bytes allocated in the heap 3,480 bytes copied during GC 44,384 bytes maximum residency (1 sample(s)) 17,056 bytes maximum slop 1 MB total memory in use (0 MB lost due to fragmentation) Tot time (elapsed) Avg pause Max pause Gen 0 0 colls, 0 par 0.000s 0.000s 0.0000s 0.0000s Gen 1 1 colls, 0 par 0.000s 0.005s 0.0049s 0.0049s INIT time 0.000s ( 0.002s elapsed) MUT time 0.010s ( 0.025s elapsed) GC time 0.000s ( 0.005s elapsed) EXIT time 0.000s ( 0.005s elapsed) Total time 0.012s ( 0.037s elapsed) %GC time 1.8% (13.1% elapsed) Alloc rate 11,904,262 bytes per MUT second Productivity 97.1% of total user, 31.2% of total elapsed real 0m0.057s user 0m0.012s sys 0m0.010s (java-1.8.0 ghc-7.10.3) ✔ ~/wrk/haskell-works/hw-tutorial-performance/hw- tutorial-performance-rwhe [master|✚ 1] 08:12 $ ghc -prof -fforce-recomp --make -O2 -funbox-strict-fields -rtsopts -optc-O2 Main.hs [1 of 1] Compiling Main ( Main.hs, Main.o ) Linking Main ... (java-1.8.0 ghc-7.10.3) ✔ ~/wrk/haskell-works/hw-tutorial-performance/hw- tutorial-performance-rwhe [master|✚ 1] 08:12 $ time ./Main +RTS -sstderr -RTS 1e7 5000000.5 3,012,099,000 bytes allocated in the heap 4,079,698,408 bytes copied during GC 1,162,199,352 bytes maximum residency (13 sample(s)) 19,313,368 bytes maximum slop 1990 MB total memory in use (0 MB lost due to fragmentation) Tot time (elapsed) Avg pause Max pause Gen 0 4869 colls, 0 par 1.046s 1.055s 0.0002s 0.0017s Gen 1 13 colls, 0 par 1.230s 1.960s 0.1508s 0.5764s INIT time 0.000s ( 0.004s elapsed) MUT time 0.963s ( 0.825s elapsed) GC time 2.276s ( 3.016s elapsed) RP time 0.000s ( 0.000s elapsed) PROF time 0.000s ( 0.000s elapsed) EXIT time 0.009s ( 0.185s elapsed) Total time 3.251s ( 4.029s elapsed) %GC time 70.0% (74.8% elapsed) Alloc rate 3,126,345,026 bytes per MUT second Productivity 30.0% of total user, 24.2% of total elapsed real 0m4.197s user 0m3.251s sys 0m0.883s }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12893> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #13637: Printing type operators adds extraneous parenthesis
by GHC 09 Dec '18

09 Dec '18

#13637: Printing type operators adds extraneous parenthesis -------------------------------------+------------------------------------- Reporter: darchon | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1-rc2 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: -------------------------------------+------------------------------------- Given the code: {{{ {-# LANGUAGE TypeOperators #-} type name ::: a = a f :: Int ::: Int -> Int f = id }}} In GHCi-8.0.2 I get: {{{ >>> :t f f :: Int ::: Int -> Int }}} But in GHCi-8.2.0.20170427 I get: {{{ >>> :t f f :: (Int ::: Int) -> Int }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13637> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #8109: Type family patterns should support as-patterns.
by GHC 09 Dec '18

09 Dec '18

#8109: Type family patterns should support as-patterns. ------------------------------------+------------------------------------- Reporter: carlhowells | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- I recently wrote code similar to the following: {{{ {-# LANGUAGE DataKinds, ScopedTypeVariables, TypeOperators, TypeFamilies #-} {-# LANGUAGE PolyKinds, FlexibleInstances, FlexibleContexts #-} import GHC.TypeLits data P n = P fromNat :: forall (p :: Nat -> *) (n :: Nat). SingI n => p n -> Integer fromNat _ = fromSing (sing :: Sing n) class C (a :: [Nat]) where type T a :: * val :: p a -> T a instance SingI n => C '[n] where type T '[n] = Integer val _ = fromNat (P :: P n) instance (SingI n, C (n2 ': ns)) => C (n ': n2 ': ns) where type T (n ': n2 ': ns) = (Integer, T (n2 ': ns)) val _ = (fromNat (P :: P n), val (P :: P (n2 ': ns))) }}} There were semantic constraints in my case that made an empty list nonsensical, so it wasn't an appropriate base case. But the resulting effort in ensuring type family patterns didn't overlap got unwieldy. I would have much preferred to write that second instance more like this: {{{ instance (SingI n, C ns) => C (n ': ns@(_ ': _)) where type T (n ': ns) = (Integer, T ns) val _ = (fromNat (P :: P n), val (P :: P ns)) }}} The reasoning here is identical to as-patterns in value-level pattern matching. If you only want to match an expression when it has a particular sub-structure, it's way more convenient to do it with an as-pattern. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8109> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 8

[GHC] #12126: Bad error messages for SPECIALIZE pragmas
by GHC 09 Dec '18

09 Dec '18

#12126: Bad error messages for SPECIALIZE pragmas -------------------------------------+------------------------------------- Reporter: antalsz | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: Specialize, | Operating System: Unknown/Multiple ErrorMessages | Architecture: | Type of failure: Incorrect Unknown/Multiple | warning at compile-time Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- When playing with SPECIALIZE pragmas, I've encountered one large problem with the error messages, and two minor ones. 1. Given a function with a `Num` constraint, applying `SPECIALIZE` at a non-function type triggers defaulting incorrectly; the code {{{#!hs f1 :: Num a => a -> a f1 x = x + x {-# SPECIALIZE f1 :: Bool #-} }}} produces the error {{{ …/Test1.hs:5:1: error: • Couldn't match expected type ‘Integer -> Integer’ with actual type ‘Bool’ • In the SPECIALISE pragma {-# SPECIALIZE f1 :: Bool #-} }}} (This is in the attached file `Test1.hs`.) 2. Given a function, applying `SPECIALIZE` at a well-formed type without the looked-for instance produces an error with some extra text (the first line ends with "a SPECIALISE pragma for ‘f2’", even though this is repeated on the next line); the code {{{#!hs f2 :: Num a => a -> a f2 x = x + x {-# SPECIALIZE f2 :: Bool -> Bool #-} }}} produces the error {{{ …/Test2.hs:5:1: error: • No instance for (Num Bool) a SPECIALISE pragma for ‘f2’ • In the SPECIALISE pragma {-# SPECIALIZE f2 :: Bool -> Bool #-} }}} (This is in the attached file `Test2.hs`.) 3. This is minor, but: both of these error messages talk about a `SPECIALISE` pragma when I wrote a `SPECIALIZE` pragma. Even more so, case is not preserved in the quoted pragma; if I provide a {{{#!hs {-# specialize … #-} }}} pragma, the error message ends with {{{ • In the SPECIALISE pragma {-# SPECIALIZE … #-}`. }}} even though that isn't what I wrote. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12126> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 8

[GHC] #13165: Speed up the RTS hash table
by GHC 09 Dec '18

09 Dec '18

#13165: Speed up the RTS hash table -------------------------------------+------------------------------------- Reporter: dobenour | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Runtime | Version: 8.1 System | 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: -------------------------------------+------------------------------------- The RTS hash table is rather slow. Every lookup involves at least one indirect call (to get a hash code). It also uses separate chaining, which is itself slow. Until recently, this didn't really matter, since the RTS hash table wasn't used for anything particularly performance critical other than `StablePtr` operations. However, it has since become the bottleneck when compacting with sharing, to the point that compacting without sharing is around 10x faster and is thus the default. Fortunately, there are easy ways to make the hash table faster. These include: - Use linear probing instead of separate chaining. - Specialize for the case of pointer keys - Don't use indirect calls for hashing - Use a fast, universal hash function for pointers. - Use SSE instructions where available to do fast searches. - Minimize the number of indirections in the use of the table. In both the case of the StablePtr table and that of compact regions, the keys of the table are not GC pointers, but the values are, so there needs to be a way to ensure that the GC handles the table correctly -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13165> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 14

[GHC] #13786: GHC panic on Mac OS X with "cabal repl" / "stack repl" on GHC 8.0.2 and 7.8.3
by GHC 07 Dec '18

07 Dec '18

#13786: GHC panic on Mac OS X with "cabal repl" / "stack repl" on GHC 8.0.2 and 7.8.3 -------------------------------------+------------------------------------- Reporter: ppelleti | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 8.0.2 Keywords: | Operating System: MacOS X Architecture: x86_64 | Type of failure: Compile-time (amd64) | crash or panic Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Using [https://github.com/ppelleti/hs-mercury-api this package], I tried doing "stack repl" with GHC 8.0.2: {{{ whiteandnerdy:hs-mercury-api ppelleti$ stack repl The following GHC options are incompatible with GHCi and have not been passed to it: -threaded * * * * * * * * The main module to load is ambiguous. Candidates are: 1. Package `mercury-api' component exe:tmr-firmware with main-is file: /Users/ppelleti/programming/haskell/hs-mercury-api/examples/tmr- firmware.hs 2. Package `mercury-api' component exe:tmr-gpio with main-is file: /Users/ppelleti/programming/haskell/hs-mercury-api/examples/tmr-gpio.hs 3. Package `mercury-api' component exe:tmr-lock with main-is file: /Users/ppelleti/programming/haskell/hs-mercury-api/examples/tmr-lock.hs 4. Package `mercury-api' component exe:tmr-params with main-is file: /Users/ppelleti/programming/haskell/hs-mercury-api/examples/tmr-params.hs 5. Package `mercury-api' component exe:tmr-read with main-is file: /Users/ppelleti/programming/haskell/hs-mercury-api/examples/tmr-read.hs 6. Package `mercury-api' component exe:tmr-write with main-is file: /Users/ppelleti/programming/haskell/hs-mercury-api/examples/tmr-write.hs You can specify which one to pick by: * Specifying targets to stack ghci e.g. stack ghci mercury-api:exe:tmr- firmware * Specifying what the main is e.g. stack ghci --main-is mercury-api:exe :tmr-firmware * Choosing from the candidate above [1..6] * * * * * * * * Specify main module to use (press enter to load none): 4 Loading main module from cadidate 4, --main-is /Users/ppelleti/programming/haskell/hs-mercury-api/examples/tmr-params.hs Configuring GHCi with the following packages: mercury-api GHCi, version 8.0.2: http://www.haskell.org/ghc/ :? for help ghc: panic! (the 'impossible' happened) (GHC version 8.0.2 for x86_64-apple-darwin): Loading temp shared object failed: dlopen(/var/folders/d1/v9ptqpx12mdcxj77509440rc0000gn/T/ghc91859_0/libghc_5.dylib, 5): Symbol not found: _TMR_SR_cmdStopReading Referenced from: /var/folders/d1/v9ptqpx12mdcxj77509440rc0000gn/T/ghc91859_0/libghc_5.dylib Expected in: flat namespace in /var/folders/d1/v9ptqpx12mdcxj77509440rc0000gn/T/ghc91859_0/libghc_5.dylib Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} This bug appears to have been around a while, because it also happens with GHC 7.8.3: {{{ whiteandnerdy:hs-mercury-api ppelleti$ cabal repl Preprocessing library mercury-api-0.1.0.0... GHCi, version 7.8.3: http://www.haskell.org/ghc/ :? for help Loading package ghc-prim ... linking ... done. Loading package integer-gmp ... linking ... done. Loading package base ... linking ... done. Loading package array-0.5.0.0 ... linking ... done. Loading package deepseq-1.3.0.2 ... linking ... done. Loading package bytestring-0.10.4.0 ... linking ... done. Loading package containers-0.5.5.1 ... linking ... done. Loading package binary-0.7.1.0 ... linking ... done. Loading package text-1.2.2.1 ... linking ... done. Loading package hashable-1.2.6.0 ... linking ... done. Loading package unordered-containers-0.2.8.0 ... linking ... done. Loading package clock-0.7.2 ... linking ... done. Loading package old-locale-1.0.0.6 ... linking ... done. Loading package time-1.4.2 ... linking ... done. Loading package unix-2.7.0.1 ... linking ... done. Loading package ansi-terminal-0.6.2.3 ... linking ... done. Loading object (static) dist/build/cbits/api/tmr_strerror.o ... done Loading object (static) dist/build/cbits/api/tmr_param.o ... done Loading object (static) dist/build/cbits/api/hex_bytes.o ... done Loading object (static) dist/build/cbits/api/tm_reader.o ... ghc: panic! (the 'impossible' happened) (GHC version 7.8.3 for x86_64-apple-darwin): Loading temp shared object failed: dlopen(/var/folders/d1/v9ptqpx12mdcxj77509440rc0000gn/T/ghc91576_0/ghc91576_4.dylib, 9): Symbol not found: _TMR_SR_SerialTransportNativeInit Referenced from: /var/folders/d1/v9ptqpx12mdcxj77509440rc0000gn/T/ghc91576_0/ghc91576_4.dylib Expected in: flat namespace in /var/folders/d1/v9ptqpx12mdcxj77509440rc0000gn/T/ghc91576_0/ghc91576_4.dylib Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} I'm using Mac OS X 10.9.5: {{{ whiteandnerdy:hs-mercury-api ppelleti$ uname -a Darwin whiteandnerdy.lan 13.4.0 Darwin Kernel Version 13.4.0: Mon Jan 11 18:17:34 PST 2016; root:xnu-2422.115.15~1/RELEASE_X86_64 x86_64 }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13786> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 14