November 2014 - ghc-tickets

[GHC] #8060: Undefined symbols when using Template Haskell linked from another object with unexposed modules
by GHC 08 Jan '16

08 Jan '16

#8060: Undefined symbols when using Template Haskell linked from another object with unexposed modules -----------------------------------+--------------------------------------- Reporter: tvynr | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Keywords: | Operating System: Linux Architecture: | Type of failure: Compile-time crash Unknown/Multiple | Test Case: Difficulty: Unknown | Blocking: Blocked By: | Related Tickets: | -----------------------------------+--------------------------------------- I have constructed two Cabal projects named "first" and "second". The "first" project defines three files: Logging.hs (which provides some basic logging functionality) and FirstExample.hs and FirstDependent.hs (the latter of which imports the former). In the cabal file, only Logging and FirstDependent are exposed modules. FirstDependent uses a Template Haskell function "loggingFunctions" which defines logging functions for that module. Using cabal or cabal-dev to build this package works quite nicely. The second project depends on the first project and contains a single file, Second.hs. This file imports Logging but neither of the other two files. It also uses the loggingFunctions routine to generate local logging functions. The presence of the "$(loggingFunctions)" splice in Second.hs makes the problem visible, but the real problem is in the first project. Upon compilation of the "second" project with cabal or cabal- dev, the following error is generated: {{{ cabal-dev -s ../cabal-dev-sandbox --with-cabal-install=cabal configure Resolving dependencies... Configuring second-0.1... cabal-dev -s ../cabal-dev-sandbox --with-cabal-install=cabal build Building second-0.1... Preprocessing library second-0.1... [1 of 1] Compiling Second ( lib-src/Second.hs, dist/build/Second.o ) Loading package ghc-prim ... linking ... done. Loading package integer-gmp ... linking ... done. Loading package base ... linking ... done. Loading package array-0.4.0.1 ... linking ... done. Loading package deepseq-1.3.0.1 ... linking ... done. Loading package containers-0.5.0.0 ... linking ... done. Loading package filepath-1.3.0.1 ... linking ... done. Loading package old-locale-1.0.0.5 ... linking ... done. Loading package time-1.4.0.1 ... linking ... done. Loading package bytestring-0.10.0.2 ... linking ... done. Loading package unix-2.6.0.1 ... linking ... done. Loading package directory-1.2.0.1 ... linking ... done. Loading package transformers-0.3.0.0 ... linking ... done. Loading package mtl-2.1.2 ... linking ... done. Loading package text-0.11.3.1 ... linking ... done. Loading package parsec-3.1.3 ... linking ... done. Loading package network-2.4.1.2 ... linking ... done. Loading package process-1.1.0.2 ... linking ... done. Loading package hslogger-1.2.1 ... linking ... done. Loading package pretty-1.1.1.0 ... linking ... done. Loading package template-haskell ... linking ... done. Loading package first-0.2 ... linking ... ghc: /home/some- directories/example/first/../cabal-dev- sandbox//lib/first-0.2/ghc-7.6.1.20121207/HSfirst-0.2.o: unknown symbol `firstzm0zi2_FirstExample_zdfShowErrorSpec3_closure' ghc: unable to load package `first-0.2' make[1]: *** [build] Error 1 }}} Upon further investigation, it would seem that the .o file constructed to represent the "first" project has not been completely constructed: {{{ $ objdump -t cabal-dev- sandbox/lib/first-0.2/ghc-7.6.1.20121207/HSfirst-0.2.o | grep '\*UND\*' | grep first 00000000 *UND* 00000000 firstzm0zi2_FirstExample_zdfOrdErrorSpeczuzdczg_info 00000000 *UND* 00000000 firstzm0zi2_FirstExample_zdfShowErrorSpec3_closure 00000000 *UND* 00000000 firstzm0zi2_FirstExample_zdfOrdErrorSpeczuzdczl_info 00000000 *UND* 00000000 firstzm0zi2_FirstExample_zdfEqErrorSpeczuzdczeze_info 00000000 *UND* 00000000 firstzm0zi2_FirstExample_zdfOrdErrorSpeczuzdczlze_info 00000000 *UND* 00000000 firstzm0zi2_FirstExample_zdfOrdErrorSpeczuzdccompare_info 00000000 *UND* 00000000 firstzm0zi2_FirstExample_zdfOrdErrorSpeczuzdczgze_info }}} (While the above dump is for ghc 7.6.1, this has also been tested on ghc 7.6.3 as well as on both i386- and amd64-based OS installs.) If the "$(loggingFunctions)" splice is removed from Second.hs, then the project builds (presumably because the logic used by non-Template Haskell projects for linking differs from that of Template Haskell projects). Fortunately, it seems that exposing every module of the "first" project resolves this issue. But please note that the FirstExample.hs and FirstDependent.hs files are completely unrelated to the Second.hs file; the latter does not depend on the former in any way. It seems strange that I can't use Template Haskell across projects without exposing all of my project modules. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8060> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #8909: ppc dyn executable compiled with ghc-7.8.1 RC2 segfaults
by GHC 07 Jan '16

07 Jan '16

#8909: ppc dyn executable compiled with ghc-7.8.1 RC2 segfaults -------------------------------+------------------------------------- Reporter: juhpetersen | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.1-rc2 Keywords: | Operating System: Unknown/Multiple Architecture: powerpc | Type of failure: Runtime crash Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | -------------------------------+------------------------------------- I built ghc-7.8.1 RC2 on ppc Fedora 21 Development with ghc-7.6.3. When I try to run dynamically linked "helloworld", it segfaults. I don't have direct access yet to a ppc box to investigate further. I guess something about the use of shared libraries on ppc is not working properly. {{{ $ cat > hello.hs main = putStrLn "hi" $ ghc -dynamic hello.hs $ ./hello Segmentation fault (core dumped) ./hello }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8909> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #8652: Cross-compiling broken for ARM/Linux target
by GHC 07 Jan '16

07 Jan '16

#8652: Cross-compiling broken for ARM/Linux target ----------------------------+---------------------------------------- Reporter: kgardas | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.7 Keywords: | Operating System: Linux Architecture: arm | Type of failure: Building GHC failed Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ----------------------------+---------------------------------------- I've attempted to cross compile GHC HEAD on Ubuntu 13.10 with ubuntu's hard-float tool-chain and LLVM. I've configured GHC with: {{{ $ ./configure --target=arm-linux-gnueabihf }}} and compiling by make works till it fails with: {{{ inplace/bin/deriveConstants --gen-header -o includes/dist- derivedconstants/header/DerivedConstants.h --tmpdir includes/dist- derivedconstants/header/ --gcc-program "/usr/bin/gcc" --gcc-flag -fno- stack-protector --gcc-flag -Iincludes --gcc-flag -Iincludes/dist --gcc- flag -Iincludes/dist-derivedconstants/header --gcc-flag -Iincludes/dist- ghcconstants/header --gcc-flag -Irts --gcc-flag -fcommon --nm-program "/usr/bin/arm-linux-gnueabihf-nm" /usr/bin/arm-linux-gnueabihf-nm: includes/dist- derivedconstants/header/tmp.o: File format not recognized deriveConstants: readProcess: /usr/bin/arm-linux-gnueabihf-nm "includes /dist-derivedconstants/header/tmp.o" (exit 1): failed make[1]: *** [includes/dist-derivedconstants/header/DerivedConstants.h] Error 1 }}} As a workaround for this issue, it's possible to use --with-gcc= and this way deriveConstants gets the right cross GCC. Looks like a bug somewhere in make machinery or configure itself. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8652> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #8560: undeducable Typeable error with data kinds when deriving Data for GADT in GHC version 7.7.20131122
by GHC 05 Jan '16

05 Jan '16

#8560: undeducable Typeable error with data kinds when deriving Data for GADT in GHC version 7.7.20131122 ------------------------------------+------------------------------------- Reporter: carter | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | 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 may be an artifact of issue #8128 (see https://ghc.haskell.org/trac/ghc/ticket/8128#comment:5) but I'm seeing examples involving data kinds where Typeable isn't deducible. This could be an artifact of other problems, BUT since with 7.7 onwards, we have baked in polykinded Typeable, things should always "just work™" right? the error with current head is as follows (and i'm attaching the code + current finger print too) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8560> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 10

[GHC] #9590: AMP breaks `haskell2010` package
by GHC 02 Jan '16

02 Jan '16

#9590: AMP breaks `haskell2010` package -------------------------------------+------------------------------------- Reporter: hvr | Owner: Type: bug | Status: new Priority: high | Milestone: 7.10.1 Component: | Version: 7.9 libraries/haskell2010 | Operating System: Keywords: AMP | Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: GHC Difficulty: Unknown | rejects valid program Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- (and probably also `haskell98`) I hate to be the one pointing this out, but the AMP has one ugly side- effect. Consider the following session: ``` $ inplace/bin/ghc-stage2 --interactive -XHaskell2010 -hide-all-packages -package haskell2010 GHCi, version 7.9.20140914: http://www.haskell.org/ghc/ :? for help Loading package ghc-prim-0.3.1.0 ... linking ... done. Loading package integer-gmp-0.5.1.0 ... linking ... done. Loading package base-4.8.0.0 ... linking ... done. Loading package array-0.5.0.1 ... linking ... done. Loading package haskell2010-1.1.2.1 ... linking ... done. λ:2> data Identity a = Identity a data Identity a = Identity a λ:3> instance Monad Identity <interactive>:3:10: No instance for (base-4.8.0.0:GHC.Base.Applicative Identity) arising from the superclasses of an instance declaration In the instance declaration for ‘Monad Identity’ λ:4> :info Monad class base-4.8.0.0:GHC.Base.Applicative m => Monad (m :: * -> *) where (>>=) :: m a -> (a -> m b) -> m b (>>) :: m a -> m b -> m b return :: a -> m a fail :: String -> m a -- Defined in ‘base-4.8.0.0:GHC.Base’ instance Monad (Either e) -- Defined in ‘base-4.8.0.0:Data.Either’ instance Monad Maybe -- Defined in ‘base-4.8.0.0:Data.Maybe’ instance Monad [] -- Defined in ‘base-4.8.0.0:GHC.Base’ instance Monad IO -- Defined in ‘base-4.8.0.0:GHC.Base’ instance Monad ((->) r) -- Defined in ‘base-4.8.0.0:GHC.Base’ λ:5> ``` -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9590> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 23

[GHC] #8182: Parser.y.pp needs special treatment with -fcmm-sink
by GHC 31 Dec '15

31 Dec '15

#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 31 Dec '15

31 Dec '15

#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] #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] #9614: ghc --print-(gcc|ld)-linker-flags broken
by GHC 29 Dec '15

29 Dec '15

#9614: ghc --print-(gcc|ld)-linker-flags broken -------------------------------------+------------------------------------- Reporter: rwbarton | 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: -------------------------------------+------------------------------------- {{{ rwbarton@morphism:~/ghc$ ghc --print-gcc-linker-flags ghc: panic! (the 'impossible' happened) (GHC version 7.8.3 for x86_64-unknown-linux): Setting not found: "Gcc Linker flags" Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug rwbarton@morphism:~/ghc$ ghc --print-ld-linker-flags ghc: panic! (the 'impossible' happened) (GHC version 7.8.3 for x86_64-unknown-linux): Setting not found: "Ld Linker flags" Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} In 2d2650bf65da3aede4e1c1ca4da623092b869dbe and subsequent commits (between 7.6 and 7.8) these settings fields became "C compiler link flags" and "ld flags". (I think, more or less.) The real problem is that Cabal still looks for the settings fields "Gcc Linker flags" and "Ld Linker flags". I guess this should be updated on the Cabal side though. (They are empty on at least Linux x86_64, which I guess is why nobody noticed before.) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9614> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 9