- ghc-tickets - Haskell.org

[GHC] #11327: GHC doesn't create dyn_o-boot files
by GHC 01 Jan '16

01 Jan '16

#11327: GHC doesn't create dyn_o-boot files -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: bug | Status: new Priority: low | Milestone: Component: Compiler | Version: 7.11 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: -------------------------------------+------------------------------------- Take any set of modules with a loop broken by an hs-boot, and run `ghc --make -dynamic-too` on it. Suppose A.hs imports B.hs, which source imports A.hs-boot; then compiling these you will get `A.{hi,o,dyn_hi,dyn_o}`, `B.{hi,o,dyn_hi,dyn_o}`, and ONLY `A.{hi- boot,o-boot,dyn_hi-boot}`: `A.dyn_o-boot` is missing. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11327> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #11322: Dysfunctional `__GLASGOW_HASKELL_TH` macro
by GHC 01 Jan '16

01 Jan '16

#11322: Dysfunctional `__GLASGOW_HASKELL_TH` macro -------------------------------------+------------------------------------- Reporter: hvr | Owner: Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 7.10.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): Phab:#1723 | Wiki Page: -------------------------------------+------------------------------------- TODO -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11322> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #8182: Parser.y.pp needs special treatment with -fcmm-sink
by GHC 01 Jan '16

01 Jan '16

#8182: Parser.y.pp needs special treatment with -fcmm-sink ------------------------------------+------------------------------------- Reporter: thoughtpolice | Owner: thoughtpolice Type: bug | Status: new Priority: highest | Milestone: 7.8.1 Component: Build System | Version: 7.7 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- This bug is really more of a reminder, but it's critical for the 7.8.1 release. Right now, `Parser.y.pp` uses a very weird hack to pass `-fcmm-sink` to the compiler. Here's the relevant comment: {{{ -- CPP tricks because we want the directives in the output of the -- first CPP pass. -- -- Clang note, 6/17/2013 by aseipp: It is *extremely* important (for -- some reason) that there be a line of whitespace between the two -- definitions here, and the subsequent use of __IF_GHC_77__ - this -- seems to be a bug in clang or something, where having the line of -- whitespace will make the preprocessor correctly format the rendered -- lines in the 'two step' CPP pass. No, this is not a joke. #define __IF_GHC_77__ #if __GLASGOW_HASKELL__ >= 707 #define __ENDIF__ #endif __IF_GHC_77__ -- Required on x86 to avoid the register allocator running out of -- stack slots when compiling this module with -fPIC -dynamic. {-# OPTIONS_GHC -fcmm-sink #-} __ENDIF__ }}} This is because the parser is first preprocessed before being run with GHC (which again preprocesses,) so we want the resulting `#ifdef` in the final `.hs` file. Things to note: * We really shouldn't be doing this, it's amazingly fragile. I think the correct thing to do is to ensure the build system correctly passes `-fcmm- sink` during the stage[2,3] build. * `./configure.ac` needs to check to see if the bootstrapping compiler is `ghc >= 7.7` (or `7.8`) and if it is, ''also'' pass `-fcmm-sink` during the stage1 build. * This hack needs to be removed once we can rely on >= 7.8 for bootstrap. Probably something like the hypothetical 7.12-7.14 timeframe. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8182> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #9734: Provide macro __GLASGOW_HASKELL_TH__
by GHC 01 Jan '16

01 Jan '16

#9734: Provide macro __GLASGOW_HASKELL_TH__ -------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: feature request | Status: new Priority: normal | Milestone: 7.10.1 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: -------------------------------------+------------------------------------- The Debian packaging added a few hacks to create a CPP macro that can be used to distinguish compilers with Template Haskell support from those that don’t have that support. We need this to compiler some code on non- TH architectures. It works, but we found that we cannot upstream such patches, which is a shame. I propose that among the GHC-defined macros listed at https://www.haskell.org/ghc/docs/latest/html/users_guide/options- phases.html#c-pre-processor there is also `__GLASGOW_HASKELL_TH__=YES`, which is available if the compiler supports splices, or ``__GLASGOW_HASKELL_TH__=NO` if not. (I propose a two-valued comparison so that library authors can decide themselves what the default should be if this symbol is not defined, some might want to use TH on older compilers, some not.) I hope this can be part of 7.10. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9734> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #11324: Missing Kind Inference
by GHC 31 Dec '15

31 Dec '15

#11324: Missing Kind Inference -------------------------------------+------------------------------------- Reporter: crockeea | 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: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- The following example doesn't compile, but I expected it to. {{{ {-# LANGUAGE RankNTypes, ConstraintKinds, ScopedTypeVariables, KindSignatures, PolyKinds, DataKinds, FlexibleInstances, UndecidableInstances, TypeFamilies #-} module Test where data Proxy a data Tagged t s = Tag s type family CharOf fp :: k class Reflects (a :: k) where value :: Proxy a instance Reflects (a :: Bool) type MyConstraint (x :: Bool) = (x~x) foo :: forall fp . (MyConstraint (CharOf fp)) => Tagged fp Int foo= let x = value::Proxy (CharOf fp) in Tag 2 }}} The error in 7.10.2 (unable to test with HEAD) is `Could not deduce (Reflects k (CharOf k fp)) arising from a use of ‘value’`, basically that it was unable to figure out the kind of `CharOf fp`. I think GHC should know the kind from the constraint on `foo`. I've found two workarounds: {{{ foo :: forall fp . (MyConstraint (CharOf fp)) => Tagged fp Int foo= let x = value::Proxy (CharOf fp :: Bin) in Tag 2 }}} and {{{ foo :: forall fp x . (MyConstraint x, x~CharOf fp) => Tagged fp Int foo= let x = value::Proxy x in Tag 2 }}} but both seem unnecessary. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11324> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #11122: Ambiguous inferred type causes a panic
by GHC 31 Dec '15

31 Dec '15

#11122: Ambiguous inferred type causes a panic -------------------------------------+------------------------------------- Reporter: tuplanolla | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 (Type checker) | Keywords: | Operating System: Linux Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Consider the following program. {{{#!hs {-# LANGUAGE PartialTypeSignatures #-} module Main where import Text.Parsec import Text.Parsec.String parser :: Parser _ parser = read <$> many digit data Wrapper = Wrapper Int wrapperParser = Wrapper <$> parser }}} I am not sure whether it is valid or not, but it breaks the type checker as follows. {{{#!hs Program.hs:9:1: No instance for (Read w_) When checking that ‘parser’ has the specified type parser :: forall w_. Parser w_ Probable cause: the inferred type is ambiguous Program.hs:13:29: Couldn't match type ‘w_’ with ‘Int’ ‘w_’ is untouchable inside the constraints () bound by the inferred type of wrapperParser :: ParsecT String () Data.Functor.Identity.Identity Wrapper at Program.hs:13:1-34ghc: panic! (the 'impossible' happened) (GHC version 7.10.2 for x86_64-unknown-linux): No skolem info: w__avnz[sk] }}} Disabling `PartialTypeSignatures` makes no difference. Switching from `parsec-3.1.9` to `megaparsec-4.1.1` and changing `many digit` to `some digitChar` does not have an effect either. Replacing `_` with `Int` seems to be the only obvious way to make the problem disappear. Alas that defeats the point of using partial type signatures or typed holes in the first place. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11122> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 9

[GHC] #11245: Non-exhaustive pattern, "Patterns not matched" list is empty
by GHC 31 Dec '15

31 Dec '15

#11245: Non-exhaustive pattern, "Patterns not matched" list is empty -------------------------------------+------------------------------------- Reporter: osa1 | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.11 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: -------------------------------------+------------------------------------- Example: {{{#!haskell module Main where maybeOdd :: Int -> Maybe Int maybeOdd i = if odd i then Just i else Nothing main :: IO () main = do let x = maybeOdd 10 let a | Just i <- x , odd i = True | Nothing <- x = False print x print a }}} Warning printed by GHC HEAD: {{{ Exhaustive.hs:10:7: warning: Pattern match(es) are non-exhaustive In an equation for ‘a’: Patterns not matched: Linking Exhaustive ... }}} The problem with this message is; if it couldn't come up with an example unmatched pattern, then how can it know that the pattern is non- exhaustive? If it came up with an example, why is that example not printed? UPDATE: I just realized it's actually worse that I first thought. If I change {{{a}}} in this example: {{{#!haskell let a | Just i <- x = True }}} This message is printed: {{{ [1 of 1] Compiling Main ( Exhaustive.hs, Exhaustive.o ) Exhaustive.hs:10:7: warning: Pattern match(es) are non-exhaustive In an equation for ‘a’: Patterns not matched: Exhaustive.hs:10:16: warning: Defined but not used: ‘i’ Linking Exhaustive ... }}} NOTE: Tried with GHC 7.10 too. It seems like in the case where the checks are not exhaustive, both 7.10 and HEAD are giving the same warning(with empty list of non-checked patterns). HEAD is better in detecting exhaustive patterns. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11245> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 12

[GHC] #9237: GHC not recognizing "-llibrary" form in implicit linker scripts
by GHC 31 Dec '15

31 Dec '15

#9237: GHC not recognizing "-llibrary" form in implicit linker scripts ----------------------------------+--------------------------------------- Reporter: mmikolajczyk | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Keywords: | Operating System: Unknown/Multiple Architecture: x86_64 (amd64) | Type of failure: Compile-time crash Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ----------------------------------+--------------------------------------- I have tried to build accelerate-llvm package and encountered an invalid behaviour of linker. I am using Arch Linux and GHC 7.8.2. I have installed llvm-general-3.4.2.2 and llvm-general-pure-3.4.2.2 from this branch: https://github.com/tvh/llvm- general/tree/curatedTargetMachine, and accelerate from HEAD to common sandbox. Then I tried to build accelerate-llvm using the sandbox and got this output during building: {{{ Building accelerate-llvm-0.15.0.0... Preprocessing library accelerate-llvm-0.15.0.0... [ 1 of 30] Compiling Data.Range.Range ( Data/Range/Range.hs, dist/build/Data/Range/Range.o ) Loading package ghc-prim ... linking ... done. Loading package integer-gmp ... linking ... done. Loading package base ... linking ... done. Loading package primitive-0.5.3.0 ... linking ... done. Loading package array-0.5.0.0 ... linking ... done. Loading package deepseq-1.3.0.2 ... linking ... done. Loading package old-locale-1.0.0.6 ... linking ... done. Loading package time-1.4.2 ... linking ... done. Loading package vector-0.10.11.0 ... linking ... done. Loading package mwc-random-0.13.1.2 ... linking ... done. Loading package bytestring-0.10.4.0 ... linking ... done. Loading package containers-0.5.5.1 ... linking ... done. Loading package transformers-0.4.1.0 ... linking ... done. Loading package mtl-2.2.1 ... linking ... done. Loading package text-1.1.1.3 ... linking ... done. Loading package parsec-3.1.5 ... linking ... done. Loading package unix-2.7.0.1 ... linking ... done. Loading package setenv-0.1.1.1 ... linking ... done. Loading package pretty-1.1.1.1 ... linking ... done. Loading package template-haskell ... linking ... done. Loading package llvm-general-pure-3.4.2.2 ... linking ... done. Loading package utf8-string-0.3.8 ... linking ... done. Loading package llvm-general-3.4.2.2 ... <command line>: can't load .so/.DLL for: /usr/lib/libcurses.so (-lncursesw: cannot open shared object file: No such file or directory) }}} After some searching I narrowed down the issue to `/usr/lib/libcurses.so` file. In Arch, this file contains `INPUT(-lncursesw)`. If I change it to `INPUT(libncursesw.so)` or `INPUT(/usr/lib/libncursesw.so)` it works fine. Symlinking `/usr/lib/libcurses.so` to `/usr/lib/libncursesw.so` also works. This bug seems to be connected to #2615. GHC still doesn't follow `INPUT` commands containing `-llibrary` form. Ld documentation allows this: {{{If you use `INPUT (-lfile)', ld will transform the name to libfile.a, as with the command line argument `-l'}}}. (https://sourceware.org/binutils/docs/ld/File-Commands.html) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9237> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 10

[GHC] #9825: ghc "panic! (the 'impossible' happened)" building vimus on NixOS
by GHC 31 Dec '15

31 Dec '15

#9825: ghc "panic! (the 'impossible' happened)" building vimus on NixOS ----------------------------+--------------------------------------------- Reporter: jzellner | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Keywords: | Operating System: Linux Architecture: x86 | Type of failure: Compile-time crash Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: ----------------------------+--------------------------------------------- Hey there, I'm having trouble building vimus (https://github.com/vimus/vimus) on NixOS. The package builds fine locally for an x64 system, but is failing on i686 builds. On the NixOS builder: http://hydra.nixos.org/build/17512103/nixlog/2 {{{ [nix-shell:/tmp/build-17512103/vimus-0.2.0]$ ./Setup clean && ./Setup configure --enable-shared --enable-library-vanilla --enable-executable- dynamic --enable-tests --ghc- option=-optl=-Wl,-rpath=/nix/store/cgkfxxk1iz30fg0r3kf9dv2p550i5hn2-vimus-0.2.0/lib/ghc-7.8.3/vimus-0.2.0 --ghc-option=-j8 && ./Setup build cleaning... Configuring vimus-0.2.0... Building vimus-0.2.0... Preprocessing library vimus-0.2.0... [ 1 of 39] Compiling Constant ( dist/build/Constant.hs, dist/build/Constant.o ) [ 2 of 39] Compiling CursesUtil ( ncursesw/src/CursesUtil.hs, dist/build/CursesUtil.o ) [ 3 of 39] Compiling Timer ( src/Timer.hs, dist/build/Timer.o ) [ 4 of 39] Compiling UI.Curses.Type ( dist/build/UI/Curses/Type.hs, dist/build/UI/Curses/Type.o ) [ 5 of 39] Compiling Misc ( dist/build/Misc.hs, dist/build/Misc.o ) ncursesw/src/Misc.chs:7:1: Warning: The import of ‘Foreign.C.String’ is redundant except perhaps to import instances from ‘Foreign.C.String’ To import instances alone, use: import Foreign.C.String() ncursesw/src/Misc.chs:8:1: Warning: The import of ‘Foreign.Marshal.Alloc’ is redundant except perhaps to import instances from ‘Foreign.Marshal.Alloc’ To import instances alone, use: import Foreign.Marshal.Alloc() ncursesw/src/Misc.chs:9:1: Warning: The import of ‘Foreign.Storable’ is redundant except perhaps to import instances from ‘Foreign.Storable’ To import instances alone, use: import Foreign.Storable() ncursesw/src/Misc.chs:10:1: Warning: The import of ‘Foreign.ForeignPtr’ is redundant except perhaps to import instances from ‘Foreign.ForeignPtr’ To import instances alone, use: import Foreign.ForeignPtr() ncursesw/src/Misc.chs:12:1: Warning: The import of ‘Data.Char’ is redundant except perhaps to import instances from ‘Data.Char’ To import instances alone, use: import Data.Char() ncursesw/src/Misc.chs:29:1: Warning: Top-level binding with no type signature: cFromBool :: Bool -> Integer ncursesw/src/Misc.chs:29:13: Warning: Defaulting the following constraint(s) to type ‘Integer’ (Num a0) arising from a use of ‘fromBool’ In the expression: fromBool In an equation for ‘cFromBool’: cFromBool = fromBool ncursesw/src/Misc.chs:30:1: Warning: Top-level binding with no type signature: cToBool :: Integer -> Bool ncursesw/src/Misc.chs:30:13: Warning: Defaulting the following constraint(s) to type ‘Integer’ (Num a0) arising from a use of ‘toBool’ at ncursesw/src/Misc.chs:30:13-18 (Eq a0) arising from a use of ‘toBool’ at ncursesw/src/Misc.chs:30:13-18 In the expression: toBool In an equation for ‘cToBool’: cToBool = toBool ncursesw/src/Misc.chs:42:1: Warning: Top-level binding with no type signature: fromAttr :: Attr -> CInt ncursesw/src/Misc.chs:77:1: Warning: Top-level binding with no type signature: wcolor_set :: Window -> Int -> IO Status ncursesw/src/Misc.chs:86:1: Warning: Top-level binding with no type signature: wattr_off :: Window -> [Attribute] -> IO Status ncursesw/src/Misc.chs:90:1: Warning: Top-level binding with no type signature: wattr_on :: Window -> [Attribute] -> IO Status ncursesw/src/Misc.chs:98:1: Warning: Top-level binding with no type signature: wchgat :: Window -> Int -> [Attribute] -> Int -> IO Status ncursesw/src/Misc.chs:103:1: Warning: Top-level binding with no type signature: mvwchgat :: Window -> Int -> Int -> Int -> [Attribute] -> Int -> IO Status [ 6 of 39] Compiling CursesInput ( dist/build/CursesInput.hs, dist/build/CursesInput.o ) [ 7 of 39] Compiling Instances ( src/Instances.hs, dist/build/Instances.o ) [ 8 of 39] Compiling Data.List.Pointed ( src/Data/List/Pointed.hs, dist/build/Data/List/Pointed.o ) [ 9 of 39] Compiling Data.List.Zipper ( src/Data/List/Zipper.hs, dist/build/Data/List/Zipper.o ) [10 of 39] Compiling UI.Curses.Key ( dist/build/UI/Curses/Key.hs, dist/build/UI/Curses/Key.o ) [11 of 39] Compiling Vimus.Tab ( src/Vimus/Tab.hs, dist/build/Vimus/Tab.o ) [12 of 39] Compiling Vimus.Command.Parser ( src/Vimus/Command/Parser.hs, dist/build/Vimus/Command/Parser.o ) [13 of 39] Compiling Vimus.Key ( src/Vimus/Key.hs, dist/build/Vimus/Key.o ) [14 of 39] Compiling Paths_vimus ( dist/build/autogen/Paths_vimus.hs, dist/build/Paths_vimus.o ) [15 of 39] Compiling Vimus.Song ( src/Vimus/Song.hs, dist/build/Vimus/Song.o ) [16 of 39] Compiling Vimus.Song.Format ( src/Vimus/Song/Format.hs, dist/build/Vimus/Song/Format.o ) [17 of 39] Compiling Vimus.Queue ( src/Vimus/Queue.hs, dist/build/Vimus/Queue.o ) [18 of 39] Compiling Vimus.Util ( src/Vimus/Util.hs, dist/build/Vimus/Util.o ) [19 of 39] Compiling Option ( src/Option.hs, dist/build/Option.o ) [20 of 39] Compiling PlaybackState ( src/PlaybackState.hs, dist/build/PlaybackState.o ) [21 of 39] Compiling Curses ( dist/build/Curses.hs, dist/build/Curses.o ) ncursesw/src/Curses.chs:73:1: Warning: The import of ‘Foreign.C.String’ is redundant except perhaps to import instances from ‘Foreign.C.String’ To import instances alone, use: import Foreign.C.String() ncursesw/src/Curses.chs:76:1: Warning: The import of ‘chr’ from module ‘Data.Char’ is redundant ncursesw/src/Curses.chs:150:1: Warning: Defined but not used: ‘wnoutrefresh’ ncursesw/src/Curses.chs:151:1: Warning: Defined but not used: ‘doupdate’ ncursesw/src/Curses.chs:152:1: Warning: Defined but not used: ‘redrawwin’ ncursesw/src/Curses.chs:153:1: Warning: Defined but not used: ‘wredrawln’ ncursesw/src/Curses.chs:160:1: Warning: Defined but not used: ‘getparyx’ ncursesw/src/Curses.chs:207:1: Warning: Defined but not used: ‘cFromBool’ ncursesw/src/Curses.chs:207:1: Warning: Top-level binding with no type signature: cFromBool :: Bool -> Integer ncursesw/src/Curses.chs:207:13: Warning: Defaulting the following constraint(s) to type ‘Integer’ (Num a0) arising from a use of ‘fromBool’ In the expression: fromBool In an equation for ‘cFromBool’: cFromBool = fromBool ncursesw/src/Curses.chs:374:1: Warning: Defined but not used: ‘wnoutrefresh'_’ ncursesw/src/Curses.chs:377:1: Warning: Defined but not used: ‘doupdate'_’ ncursesw/src/Curses.chs:380:1: Warning: Defined but not used: ‘redrawwin'_’ ncursesw/src/Curses.chs:383:1: Warning: Defined but not used: ‘wredrawln'_’ ncursesw/src/Curses.chs:389:1: Warning: Defined but not used: ‘getparyx'_’ [22 of 39] Compiling UI.Curses ( ncursesw/src/UI/Curses.hs, dist/build/UI/Curses.o ) [23 of 39] Compiling Vimus.WindowLayout ( src/Vimus/WindowLayout.hs, dist/build/Vimus/WindowLayout.o ) [24 of 39] Compiling Vimus.Widget.Type ( src/Vimus/Widget/Type.hs, dist/build/Vimus/Widget/Type.o ) [25 of 39] Compiling Content ( src/Content.hs, dist/build/Content.o ) [26 of 39] Compiling Vimus.Input ( src/Vimus/Input.hs, dist/build/Vimus/Input.o ) [27 of 39] Compiling Vimus.Macro ( src/Vimus/Macro.hs, dist/build/Vimus/Macro.o ) [28 of 39] Compiling Vimus.Render ( src/Vimus/Render.hs, dist/build/Vimus/Render.o ) [29 of 39] Compiling Vimus.Ruler ( src/Vimus/Ruler.hs, dist/build/Vimus/Ruler.o ) [30 of 39] Compiling Vimus.Type ( src/Vimus/Type.hs, dist/build/Vimus/Type.o ) [31 of 39] Compiling Vimus.Command.Type ( src/Vimus/Command/Type.hs, dist/build/Vimus/Command/Type.o ) [32 of 39] Compiling Vimus.Command.Help ( src/Vimus/Command/Help.hs, dist/build/Vimus/Command/Help.o ) [33 of 39] Compiling Vimus.Command.Completion ( src/Vimus/Command/Completion.hs, dist/build/Vimus/Command/Completion.o ) [34 of 39] Compiling Vimus.Command.Core ( src/Vimus/Command/Core.hs, dist/build/Vimus/Command/Core.o ) [35 of 39] Compiling Vimus.Widget.ListWidget ( src/Vimus/Widget/ListWidget.hs, dist/build/Vimus/Widget/ListWidget.o ) [36 of 39] Compiling Vimus.Widget.TextWidget ( src/Vimus/Widget/TextWidget.hs, dist/build/Vimus/Widget/TextWidget.o ) [37 of 39] Compiling Vimus.Widget.HelpWidget ( src/Vimus/Widget/HelpWidget.hs, dist/build/Vimus/Widget/HelpWidget.o ) [38 of 39] Compiling Vimus.Command ( src/Vimus/Command.hs, dist/build/Vimus/Command.o ) 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 text-1.2.0.0 ... linking ... done. Loading package hashable-1.2.2.0 ... linking ... done. Loading package scientific-0.3.3.2 ... linking ... done. Loading package attoparsec-0.12.1.2 ... linking ... done. Loading package setlocale-1.0.0.1 ... linking ... done. Loading package utf8-string-0.3.8 ... linking ... done. Loading package wcwidth-0.0.2 ... linking ... done. Loading package pretty-1.1.1.1 ... linking ... done. Loading package template-haskell ... linking ... done. Loading package filepath-1.3.0.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 directory-1.2.1.0 ... linking ... done. Loading package process-1.2.0.0 ... linking ... done. Loading package data-default-class-0.0.1 ... linking ... done. Loading package data-default-instances-base-0.0.1 ... linking ... done. Loading package data-default-instances-containers-0.0.1 ... linking ... done. Loading package dlist-0.7.1 ... linking ... done. Loading package data-default-instances-dlist-0.0.1 ... linking ... done. Loading package data-default-instances-old-locale-0.0.1 ... linking ... done. Loading package data-default-0.5.3 ... linking ... done. Loading package transformers-0.3.0.0 ... linking ... done. Loading package mtl-2.1.3.1 ... linking ... done. Loading package network-2.6.0.2 ... linking ... done. Loading package libmpd-0.9.0.1 ... linking ... done. <no location info>: ghc: panic! (the 'impossible' happened) (GHC version 7.8.3 for i386-unknown-linux): Loading temp shared object failed: /tmp/ghc6364_1/ghc6364_192.so: undefined symbol: nm_getyx Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug [nix-shell:/tmp/build-17512103/vimus-0.2.0]$ nixos-version 14.11pre52840.c347f1c (Caterpillar) [nix-shell:/tmp/build-17512103/vimus-0.2.0]$ ghc --version The Glorious Glasgow Haskell Compilation System, version 7.8.3 [nix-shell:/tmp/build-17512103/vimus-0.2.0]$ uname -a Linux ip-10-83-15-102.us-west-2.compute.internal 3.12.30 #1-NixOS SMP Thu Jan 1 00:00:01 UTC 1970 x86_64 GNU/Linux }}} Thanks for any help! -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9825> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #10761: GHC panic when compiling vimus: failed to map segment from shared object
by GHC 31 Dec '15

31 Dec '15

#10761: GHC panic when compiling vimus: failed to map segment from shared object -------------------------------------+------------------------------------- Reporter: haasn | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Keywords: | Operating System: Linux Architecture: x86_64 | Type of failure: Compile-time (amd64) | crash Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- When trying to build https://github.com/vimus/vimus I get a GHC panic on a specific module: {{{ λ cabal build Building vimus-0.2.1... Preprocessing library vimus-0.2.1... [38 of 39] Compiling Vimus.Command ( src/Vimus/Command.hs, dist/build/Vimus/Command.o ) ghc: panic! (the 'impossible' happened) (GHC version 7.10.2 for x86_64-unknown-linux): Loading temp shared object failed: /tmp/ghc17990_0/libghc_39.so: failed to map segment from shared object Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} I don't know why it's only this particular module of this particular library that fails. I'm running a kernel with GrSecurity and PaX enabled, and am using a hardened GCC toolchain (although Gentoo seems to automatically disable PIE for Haskell packages). -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10761> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 8