March 2019 - ghc-tickets

[GHC] #11514: Impredicativity is still sneaking in
by GHC 22 Mar '19

22 Mar '19

#11514: Impredicativity is still sneaking in -------------------------------------+------------------------------------- Reporter: goldfire | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.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: -------------------------------------+------------------------------------- This is erroneously accepted: {{{ {-# LANGUAGE RankNTypes #-} module Bug where foo :: forall a. (Show a => a -> a) -> () foo = undefined }}} `undefined` is being instantiated at `(Show a => a -> a) -> ()`, which requires impredicativity. GHC does the right thing (reject!) if we try to instantiate with a type involving proper foralls. I imagine this is a simple missing check. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11514> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #14828: panic! when using :print on some functions with class constraints?
by GHC 22 Mar '19

22 Mar '19

#14828: panic! when using :print on some functions with class constraints? -------------------------------------+------------------------------------- Reporter: jol | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 8.2.2 Keywords: | Operating System: Linux Architecture: x86_64 | Type of failure: Compile-time (amd64) | crash or panic Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- These are the problematic ones I've found: {{{ > :t foldl foldl :: Foldable t => (b -> a -> b) -> b -> t a -> b > :print foldl ghc: panic! (the 'impossible' happened) (GHC version 8.2.2 for x86_64-unknown-linux): isUnliftedType t1_a1H7[rt] :: TYPE t_a1H6[rt] Call stack: CallStack (from HasCallStack): prettyCurrentCallStack, called at compiler/utils/Outputable.hs:1133:58 in ghc:Outputable callStackDoc, called at compiler/utils/Outputable.hs:1137:37 in ghc:Outputable pprPanic, called at compiler/types/Type.hs:1952:10 in ghc:Type Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug > :t fmap fmap :: Functor f => (a -> b) -> f a -> f b > :print fmap ghc: panic! (the 'impossible' happened) (GHC version 8.2.2 for x86_64-unknown-linux): isUnliftedType t1_a1Hu[rt] :: TYPE t_a1Ht[rt] Call stack: CallStack (from HasCallStack): prettyCurrentCallStack, called at compiler/utils/Outputable.hs:1133:58 in ghc:Outputable callStackDoc, called at compiler/utils/Outputable.hs:1137:37 in ghc:Outputable pprPanic, called at compiler/types/Type.hs:1952:10 in ghc:Type Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug > :t return return :: Monad m => a -> m a > :print return ghc: panic! (the 'impossible' happened) (GHC version 8.2.2 for x86_64-unknown-linux): isUnliftedType t1_a1Wt[rt] :: TYPE t_a1Ws[rt] Call stack: CallStack (from HasCallStack): prettyCurrentCallStack, called at compiler/utils/Outputable.hs:1133:58 in ghc:Outputable callStackDoc, called at compiler/utils/Outputable.hs:1137:37 in ghc:Outputable pprPanic, called at compiler/types/Type.hs:1952:10 in ghc:Type Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug > :t pure pure :: Applicative f => a -> f a > :print pure ghc: panic! (the 'impossible' happened) (GHC version 8.2.2 for x86_64-unknown-linux): isUnliftedType t1_a1WP[rt] :: TYPE t_a1WO[rt] Call stack: CallStack (from HasCallStack): prettyCurrentCallStack, called at compiler/utils/Outputable.hs:1133:58 in ghc:Outputable callStackDoc, called at compiler/utils/Outputable.hs:1137:37 in ghc:Outputable pprPanic, called at compiler/types/Type.hs:1952:10 in ghc:Type Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} These that don't have constraints are fine: {{{ > :print id id = (_t1::a -> a) > :print map map = (_t2::(a1 -> b) -> [a1] -> [b]) > :print const const = (_t3::a2 -> b1 -> a2) }}} This value and function created in the session are fine: {{{ > let x :: Monad m => m (); x = return () Prelude| > :p x x = (_t5::Monad m1 => m1 ()) > let f :: Monad m => Int -> m Int; f n = return (n + 1) Prelude| > :p f f = (_t6::Monad m2 => Int -> m2 Int) }}} mempty and mappend imported from Data.Monoid are fine: {{{ > :m + Data.Monoid > :p mempty mempty = (_t7::Monoid a4 => a4) > :p mappend mappend = (_t8::Monoid a4 => a4 -> a4 -> a4) }}} foldl' and foldr imported from Data.List are not fine: {{{ > :m + Data.List > :p foldl' ghc: panic! (the 'impossible' happened) (GHC version 8.2.2 for x86_64-unknown-linux): isUnliftedType t1_a6Qy[rt] :: TYPE t_a6Qx[rt] Call stack: CallStack (from HasCallStack): prettyCurrentCallStack, called at compiler/utils/Outputable.hs:1133:58 in ghc:Outputable callStackDoc, called at compiler/utils/Outputable.hs:1137:37 in ghc:Outputable pprPanic, called at compiler/types/Type.hs:1952:10 in ghc:Type Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug > :p Data.List.foldr ghc: panic! (the 'impossible' happened) (GHC version 8.2.2 for x86_64-unknown-linux): isUnliftedType t2_a6RG[rt] :: TYPE t1_a6RF[rt] Call stack: CallStack (from HasCallStack): prettyCurrentCallStack, called at compiler/utils/Outputable.hs:1133:58 in ghc:Outputable callStackDoc, called at compiler/utils/Outputable.hs:1137:37 in ghc:Outputable pprPanic, called at compiler/types/Type.hs:1952:10 in ghc:Type Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} but `all` and `init` from that same module are fine: {{{ > :p Data.List.all all = (_t13::Foldable t1 => (a22 -> Bool) -> t1 a22 -> Bool) > :p Data.List.init init = (_t14::[a29] -> [a29]) }}} So, in a given module, among functions with class constraints, some have the error and others don't. I haven't found a value that's not a function with the error, and I haven't found a function with no class constraints exhibit the error. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14828> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

[GHC] #16386: T16219 fails on Windows
by GHC 22 Mar '19

22 Mar '19

#16386: T16219 fails on Windows ----------------------------------------+--------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.10.1 Component: Compiler | Version: 8.4.3 Keywords: | Operating System: Windows Architecture: Unknown/Multiple | Type of failure: None/Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: ----------------------------------------+--------------------------------- {{{ =====> T16219(normal) 85 of 6839 [0, 0, 0] cd "backpack/cabal/T16219/T16219.run" && $MAKE -s --no-print-directory T16219 CLEANUP=1 Wrong exit code for T16219()(expected 0 , actual 2 ) Stderr ( T16219 ): C:\GitLabRunner\builds\8fc0e283\0\ghc\ghc\inplace\lib\../mingw/bin\ar.exe: dist\build\backpack- issue-0.1.0.0-60IHJZyC3G628wj7263Sr0-library-a+Dil0EMVFuE1Kv7vqZWLGcN\objs-3388 \libHSbackpack- issue-0.1.0.0-60IHJZyC3G628wj7263Sr0-library-a+Dil0EMVFuE1Kv7vqZWLGcN.a: No such file or directory make[2]: *** [Makefile:12: T16219] Error 1 *** unexpected failure for T16219(normal) =====> bkpcabal03(normal) 88 of 6839 [0, 1, 0] }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/16386> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #16388: T15904 fails on Windows
by GHC 22 Mar '19

22 Mar '19

#16388: T15904 fails on Windows ----------------------------------------+--------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.10.1 Component: Compiler | Version: 8.6.3 Keywords: | Operating System: Windows Architecture: Unknown/Multiple | Type of failure: None/Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: ----------------------------------------+--------------------------------- {{{ =====> T15904(normal) 2036 of 6839 [0, 6, 0] cd "hp2ps/T15904.run" && $MAKE -s --no-print-directory T15904 Wrong exit code for T15904()(expected 0 , actual 2 ) Stdout ( T15904 ): [1 of 1] Compiling T15904 ( T15904.hs, T15904.o ) Linking "T15904".exe ... Stderr ( T15904 ): "T15904".exe.manifest: openFile: invalid argument (Invalid argument) make[2]: *** [Makefile:7: T15904] Error 1 *** unexpected failure for T15904(normal) }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/16388> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #16389: T16190 fails on Windows
by GHC 22 Mar '19

22 Mar '19

#16389: T16190 fails on Windows ----------------------------------------+--------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.10.1 Component: Compiler | Version: 8.6.3 Keywords: | Operating System: Windows Architecture: Unknown/Multiple | Type of failure: None/Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: ----------------------------------------+--------------------------------- {{{ =====> T16190(normal) 3408 of 6839 [0, 7, 0] cd "perf/compiler/T16190.run" && "/c/GitLabRunner/builds/8fc0e283/0/ghc/ghc/inplace/bin/ghc-stage2.exe" --make T16190.hs -dstg-lint -no-user-package-db -rtsopts -fno-warn- missed-specialisations -fshow-warning-groups -fdiagnostics-color=never -fno-diagnostics-show-caret -Werror=compat -dno-debug-output -v0 Compile failed (exit code 1) errors were: C:\\GitLabRunner\\builds\\8fc0e283\\0\\ghc\\ghc\\tmp\\ghc368_0\\ghc_5.s: Assembler messages: C:\\GitLabRunner\\builds\\8fc0e283\\0\\ghc\\ghc\\tmp\\ghc368_0\\ghc_5.s:5: Error: file not found: C:GitLabRunneruildsfc0e283 `gcc.exe' failed in phase `Assembler'. (Exit code: 1) *** unexpected failure for T16190(normal) }}} There is some use of TemplateHaskell's `embedBytes`. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/16389> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #16390: T10672 fails
by GHC 22 Mar '19

22 Mar '19

#16390: T10672 fails ----------------------------------------+--------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.10.1 Component: Compiler | Version: 8.6.3 Keywords: | Operating System: Windows Architecture: Unknown/Multiple | Type of failure: None/Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: ----------------------------------------+--------------------------------- This test, which is only run on Windows, seems to be reliably timing out. Marking as broken. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/16390> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #16387: Duplicate vsnwprintf symbol on Windows
by GHC 22 Mar '19

22 Mar '19

#16387: Duplicate vsnwprintf symbol on Windows -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 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: -------------------------------------+------------------------------------- Leading to failure of `T5836`: ``` Stderr ( T5836 ): GHC runtime linker: fatal error: I found a duplicate definition for symbol __mingw_vsnwprintf whilst processing object file C:\GitLabRunner\builds\8fc0e283\0\ghc\ghc\inplace\mingw\x86_64-w64-mingw32\lib\libmingwex.a The symbol was previously defined in (GHCi built-in symbols) This could be caused by: * Loading two different object files which export the same symbol * Specifying the same object file twice on the GHCi command line * An incorrect `package.conf' entry, causing some object to be loaded twice. ghc-stage2.exe: panic! (the 'impossible' happened) (GHC version 8.9.20190303 for x86_64-unknown-mingw32): loadArchive "C:\\GitLabRunner\\builds\\8fc0e283\\0\\ghc\\ghc\\inplace\\mingw\\x86_64-w64-mingw32\\lib\\libmingwex.a": failed Please report this as a GHC bug: https://www.haskell.org/ghc/reportabug *** unexpected failure for T5836(ghci) ``` -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/16387> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 17

[GHC] #13101: Enable GHC to be loaded into GHCi
by GHC 18 Mar '19

18 Mar '19

#13101: Enable GHC to be loaded into GHCi -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: task | Status: new Priority: normal | Milestone: 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: -------------------------------------+------------------------------------- It would be very helpful for development to be able to load GHC itself into GHCi. In principle this shouldn't be so hard since GHC is just another Haskell program. However, in practice there are a number of modules which use unboxed tuples, which the interpreter does not support. However, it should be possible to the convince GHC to use object code for just these modules and interpret the rest. I have a few attempts at this here (https://gist.github.com/bgamari/bd53e4fd6f3323599387ffc7b11d1a1e) See the following related mailing list threads, * https://mail.haskell.org/pipermail/ghc-devs/2017-January/013545.html * https://mail.haskell.org/pipermail/ghc-devs/2016-March/011555.html -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13101> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #15454: Have GHCi automatically use -fobject-code for modules that use UnboxedTuples
by GHC 18 Mar '19

18 Mar '19

#15454: Have GHCi automatically use -fobject-code for modules that use UnboxedTuples -------------------------------------+------------------------------------- Reporter: mgsloan | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 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: -------------------------------------+------------------------------------- This is related to a relatively old issue, that the bytecode interpreter cannot handle UnboxedTuples: https://ghc.haskell.org/trac/ghc/ticket/1257 . Rather than fix that issue, which sounds quite challenging, how about adding some automagic to GHCi which builds object code for modules that use UnboxedTuples? This is a bit trickier than just compiling those modules to object code, because object code cannot be linked against byte code (see https://ghc.haskell.org/trac/ghc/ticket/10965) A potential solution to this is to also build all of the dependencies of modules that use UnboxedTuples using object code. This idea has some precedent, though as an external script - see https://ghc.haskell.org/trac/ghc/ticket/13101 and https://gist.github.com/bgamari/bd53e4fd6f3323599387ffc7b11d1a1e . I think it would be best to put the solution to this directly in GHCi. What do you think? If y'all think it is a good idea, then I can volunteer to try to make it happen. As described in that ticket, this would be particularly helpful for loading GHC into GHCi, because GHC's code uses UnboxedTuples. Currently, `-fobject-code` must be used, which means that the speedup from using GHCi isn't quite as much as it could be. It is possible to get around this by first loading it with object code and then doing another load without object code, but that's rather inconvenient. Since this may be a surprising behavior change (the user may not have specified -odir and -hidir), it could possibly be enabled via a flag. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15454> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

[GHC] #12770: Shrink list of RUNPATH entries for GHC libraries
by GHC 16 Mar '19

16 Mar '19

#12770: Shrink list of RUNPATH entries for GHC libraries -------------------------------------+------------------------------------- Reporter: slyfox | Owner: Type: bug | Status: new Priority: normal | Milestone: 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: -------------------------------------+------------------------------------- Recently Cabal/GHC acquired '''dynamic-library-dirs''' file tag support in ''' .conf''' files. Cabal-HEAD when used with GHC-HEAD puts all shared libraries into a single directory except the GHC itself (a fallout of https://github.com/haskell/cabal/issues/4046 ). In https://github.com/haskell/cabal/issues/4046#issuecomment-256603828 Christiaan explains our current sources of RUNPATH tags. Basically, current GHC dynamic library layout is still per-directory: {{{ /usr/lib64/ghc-8.1.20161026/Cabal-1.25.0.0/libHSCabal-1.25.0.0-ghc8.1.20161026.so /usr/lib64/ghc-8.1.20161026/array-0.5.1.1/libHSarray-0.5.1.1-ghc8.1.20161026.so /usr/lib64/ghc-8.1.20161026/base-4.9.0.0/libHSbase-4.9.0.0-ghc8.1.20161026.so /usr/lib64/ghc-8.1.20161026/binary-0.8.3.0/libHSbinary-0.8.3.0-ghc8.1.20161026.so /usr/lib64/ghc-8.1.20161026/bytestring-0.10.8.1/libHSbytestring-0.10.8.1-ghc8.1.20161026.so /usr/lib64/ghc-8.1.20161026/compact-1.0.0.0/libHScompact-1.0.0.0-ghc8.1.20161026.so /usr/lib64/ghc-8.1.20161026/containers-0.5.7.1/libHScontainers-0.5.7.1-ghc8.1.20161026.so /usr/lib64/ghc-8.1.20161026/deepseq-1.4.2.0/libHSdeepseq-1.4.2.0-ghc8.1.20161026.so /usr/lib64/ghc-8.1.20161026/directory-1.2.6.2/libHSdirectory-1.2.6.2-ghc8.1.20161026.so /usr/lib64/ghc-8.1.20161026/filepath-1.4.1.0/libHSfilepath-1.4.1.0-ghc8.1.20161026.so /usr/lib64/ghc-8.1.20161026/ghc-8.1/libHSghc-8.1-ghc8.1.20161026.so /usr/lib64/ghc-8.1.20161026/ghc-boot-8.1/libHSghc- boot-8.1-ghc8.1.20161026.so /usr/lib64/ghc-8.1.20161026/ghc-boot-th-8.1/libHSghc-boot- th-8.1-ghc8.1.20161026.so /usr/lib64/ghc-8.1.20161026/ghc-prim-0.5.0.0/libHSghc- prim-0.5.0.0-ghc8.1.20161026.so /usr/lib64/ghc-8.1.20161026/ghci-8.1/libHSghci-8.1-ghc8.1.20161026.so /usr/lib64/ghc-8.1.20161026/haskeline-0.7.2.3/libHShaskeline-0.7.2.3-ghc8.1.20161026.so /usr/lib64/ghc-8.1.20161026/hoopl-3.10.2.1/libHShoopl-3.10.2.1-ghc8.1.20161026.so /usr/lib64/ghc-8.1.20161026/hpc-0.6.0.3/libHShpc-0.6.0.3-ghc8.1.20161026.so /usr/lib64/ghc-8.1.20161026/integer-gmp-1.0.0.1/libHSinteger- gmp-1.0.0.1-ghc8.1.20161026.so /usr/lib64/ghc-8.1.20161026/pretty-1.1.3.3/libHSpretty-1.1.3.3-ghc8.1.20161026.so /usr/lib64/ghc-8.1.20161026/process-1.4.2.0/libHSprocess-1.4.2.0-ghc8.1.20161026.so /usr/lib64/ghc-8.1.20161026/rts/libHSrts-ghc8.1.20161026.so /usr/lib64/ghc-8.1.20161026/rts/libHSrts_debug-ghc8.1.20161026.so /usr/lib64/ghc-8.1.20161026/rts/libHSrts_l-ghc8.1.20161026.so /usr/lib64/ghc-8.1.20161026/rts/libHSrts_thr-ghc8.1.20161026.so /usr/lib64/ghc-8.1.20161026/rts/libHSrts_thr_debug-ghc8.1.20161026.so /usr/lib64/ghc-8.1.20161026/rts/libHSrts_thr_l-ghc8.1.20161026.so /usr/lib64/ghc-8.1.20161026/template-haskell-2.11.0.0/libHStemplate- haskell-2.11.0.0-ghc8.1.20161026.so /usr/lib64/ghc-8.1.20161026/terminfo-0.4.0.2/libHSterminfo-0.4.0.2-ghc8.1.20161026.so /usr/lib64/ghc-8.1.20161026/time-1.6.0.1/libHStime-1.6.0.1-ghc8.1.20161026.so /usr/lib64/ghc-8.1.20161026/transformers-0.5.2.0/libHStransformers-0.5.2.0-ghc8.1.20161026.so /usr/lib64/ghc-8.1.20161026/unix-2.7.2.0/libHSunix-2.7.2.0-ghc8.1.20161026.so /usr/lib64/ghc-8.1.20161026/xhtml-3000.2.1/libHSxhtml-3000.2.1-ghc8.1.20161026.so }}} Could we store them exactly as Cabal does? Namely {{{ dynamic-library-dirs: /usr/lib64/x86_64-linux-ghc-8.1.20161026 }}} Then for globally installed packages (how distributions usually build packages) we would have exactly one RUNPATH. Currently we have: {{{ $ readelf -a /usr/bin/read-idiii | grep RUNPATH 0x000000000000001d (RUNPATH) Library runpath: [/usr/lib64/ghc-8.1.20161026/array-0.5.1.1:/usr/lib64/ghc-8.1.20161026/base-4.9.0.0:/usr/lib64/ghc-8.1.20161026/binary-0.8.3.0:/usr/lib64/ghc-8.1.20161026/bytestring-0.10.8.1:/usr/lib64/ghc-8.1.20161026/containers-0.5.7.1:/usr/lib64/ghc-8.1.20161026/deepseq-1.4.2.0:/usr/lib64/ghc-8.1.20161026/directory-1.2.6.2:/usr/lib64/ghc-8.1.20161026/filepath-1.4.1.0:/usr/lib64/ghc-8.1.20161026 /ghc-prim-0.5.0.0:/usr/lib64/ghc-8.1.20161026/integer- gmp-1.0.0.1:/usr/lib64/ghc-8.1.20161026/process-1.4.2.0:/usr/lib64/ghc-8.1.20161026/rts:/usr/lib64/ghc-8.1.20161026/time-1.6.0.1:/usr/lib64/ghc-8.1.20161026/transformers-0.5.2.0:/usr/lib64/ghc-8.1.20161026/unix-2.7.2.0:/usr/lib64/x86_64 -linux-ghc-8.1.20161026] }}} And that could be just single {{{ /usr/lib64/x86_64-linux-ghc-8.1.20161026 }}} It's close to ticket #11587. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12770> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3