November 2014 - ghc-tickets

[GHC] #9101: Build 7.8.2 from sources on Windows/msys2
by GHC 09 Jun '15

09 Jun '15

#9101: Build 7.8.2 from sources on Windows/msys2 ------------------------------------+--------------------------------- Reporter: cchantep | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Keywords: | Operating System: Windows Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+--------------------------------- Hi, Trying to build GHC 7.8.2 from sources on Windows 7, from msys2 shell, required binaries such as gcc, ld, ar are forced to those in inplace directories (windows-extra), even system/env provide such tools (e.g. using pacman package manager in msys2): https://ghc.haskell.org/trac/ghc/browser/ghc/configure.ac#L274 . It leads to issues as tools in inplace are quite old. Particularly it can be critical about linking: GHC will be working with old ld, but you can have built/linked libraries using the more recent ld. Then, what's built using system tool can't be used throught GHC (ld version conflict). -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9101> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #9626: Test command lines munged on Windows when running on msys Python
by GHC 09 Jun '15

09 Jun '15

#9626: Test command lines munged on Windows when running on msys Python -------------------------------------+------------------------------------- Reporter: gintas | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 7.9 Keywords: | Operating System: Windows Architecture: Unknown/Multiple | Type of failure: Building Difficulty: Unknown | GHC failed Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- On Windows, the test runner works fine if run under Windows-native Python, but fails with the msys Python because of the heuristic transformations that msys applies to all binary invocations of non-msys binaries (such as timeout.exe) by msys binaries (such as python). This is relatively easy to sidestep by going through /usr/bin/cmd in msys which sidesteps the argument munging. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9626> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

[GHC] #9259: GHCi should list its available command line options
by GHC 08 Jun '15

08 Jun '15

#9259: GHCi should list its available command line options -------------------------------------------+------------------------------- Reporter: jstolarek | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Driver | Version: Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Easy (less than 1 hour) | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: -------------------------------------------+------------------------------- GHC can now list its command line options with `--show-options` (#7843). GHCi should be able to do the same. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9259> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 13

[GHC] #8244: Removing the Cabal dependency
by GHC 06 Jun '15

06 Jun '15

#8244: Removing the Cabal dependency ------------------------------------+------------------------------------- Reporter: nh2 | Owner: Type: bug | 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: | ------------------------------------+------------------------------------- GHC depends on cabal, which is so far has been problematic many times, for many reasons. A few discussions include: * http://www.haskell.org/pipermail/haskell-cafe/2013-September/108746.html * http://www.haskell.org/pipermail/ghc-devs/2013-March/000821.html GHC uses only a very small part of Cabal, in these files: {{{ ./compiler/ghci/Linker.lhs ./compiler/main/Packages.lhs ./compiler/main/PackageConfig.hs ./compiler/main/Finder.lhs }}} plus 1 file for ghc-pkg: ./utils/ghc-pkg/Main.hs (see http://www.haskell.org/pipermail/haskell-cafe/2013-September/108750.html for details). It was proposed that either * the package format could be a plain specification without direct code dependencies * the Cabal package could be split off into Cabal-the-build-system and a minimal part to describe the package DB to be shared by Cabal and GHC The Cabal part that is used is in only a few modules of Distribution.* while the remaining majority of the Cabal-the-library package is not used (e.g. none of Distribution.Simple.*). Decoupling GHC and Cabal seems to be a public desire, yet there are some problems with these approaches. Let us discuss them in this ticket. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8244> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 38

[GHC] #8723: sdist should not have to build everything
by GHC 04 Jun '15

04 Jun '15

#8723: sdist should not have to build everything ----------------------------------------------+---------------------------- Reporter: nomeata | Owner: Type: task | Status: new Priority: low | Milestone: Component: Build System | Version: 7.6.3 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Moderate (less than a day) | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: ----------------------------------------------+---------------------------- It would be nice if instead of {{{ $ perl boot $ ./configure $ make $ make sdist }}} it would suffice to run {{{ $ perl boot $ ./configure $ make sdist }}} and if that would not build more than necessary to generate the tarballs. It would save time on the GHC-HEAD-Debian-Package-autobuilder that I am currently working on. I might look into this bug eventually, but if someone else feels like doing it: Even better. (Difficulty estimated conservatively; might well be less than an hour, besides maybe waiting for test runs to finish :-)) Remember to update MakingReleases and Building/StandardTargets if this is implemented. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8723> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #9507: ghc-pkg mode to query by package-key
by GHC 04 Jun '15

04 Jun '15

#9507: ghc-pkg mode to query by package-key -------------------------------------+------------------------------------- Reporter: ezyang | Owner: ezyang Type: feature request | Status: new Priority: normal | Milestone: Component: ghc-pkg | Version: 7.9 Keywords: backpack | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Right now, ghc-pkg understands package names and IPIDs. It should support package keys too. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9507> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #9506: Name libraries (dll/so) separately from linker symbols
by GHC 03 Jun '15

03 Jun '15

#9506: Name libraries (dll/so) separately from linker symbols -------------------------------------+------------------------------------- Reporter: ezyang | Owner: ezyang Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 Keywords: backpack | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Tracking ticket so I don't forget. Based on feedback on `#ghc`, it sounds like it would be helpful if library names on the file system only had their full package name, e.g. `libHScontainers_HASH.so` as opposed to the abbreviated package name. Additionally, it seems less necessary to provide the abbreviated package name in linker symbols, since the modules often give a pretty good clue (and the package key can be looked up.) So let's do this, and make things better for users. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9506> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

[GHC] #8292: linker_unload test doesn't work on Windows
by GHC 31 May '15

31 May '15

#8292: linker_unload test doesn't work on Windows ------------------------------------+---------------------------------- Reporter: ezyang | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: Component: Test Suite | Version: 7.7 Keywords: | Operating System: Windows Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: linker_unload Blocked By: | Blocking: Related Tickets: | ------------------------------------+---------------------------------- I fixed up the major issues but I am getting: {{{ "/c/Users/ezyang/Dev/ghc-dyn/inplace/bin/ghc-stage2.exe" -fforce-recomp -dcore-lint -dcmm-lint -dno-debug-output -no-user-package-db -rtsopts -c Test.hs -v0 # -rtsopts causes a warning "/c/Users/ezyang/Dev/ghc-dyn/inplace/bin/ghc-stage2.exe" -fforce-recomp -dcore-lint -dcmm-lint -dno-debug-output -no-user-package-db linker_unload.c -o linker_unload -no-hs-main -optc-Werror ./linker_unload \Users\ezyang\Dev\ghc-dyn\libraries\base\dist- install\build/libHSbase-4.7.0.0.a \Users\ezyang\Dev\ghc-dyn\libraries\ghc-prim\dist-install\build/libHSghc- prim-0.3.1.0.a \Users \ezyang\Dev\ghc-dyn\libraries\integer-gmp\dist-install\build/libHSinteger- gmp-0.5.1.0.a linker_unload.exe: \Users\ezyang\Dev\ghc-dyn\libraries\base\dist- install\build/libHSbase-4.7.0. 0.a: unknown symbol `_select' }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8292> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #9584: Interface file errors (Iface type variable out of scope: k)
by GHC 26 May '15

26 May '15

#9584: Interface file errors (Iface type variable out of scope: k) -------------------------------------+------------------------------------- Reporter: jonsterling | 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: -------------------------------------+------------------------------------- (Please forgive me if I have not formatted this bug report properly) Anyway, yesterday in a project at work we started having a strange problem where pretty much any change in our code at all would result in the next build failing with this error: {{{ The interface for ‘main:HList’ Declaration for $fRLensk:r_$s$w$crlens: Iface type variable out of scope: k Cannot continue after interface file error }}} I can get around the problem by deleting the dist directory, but this is very unfortunate, since it basically changes my build/test cycle from a few seconds to a minutes because I can't take advantage of the cached builds of things that *haven't* changed. It seems like errors like this have cropped up a few times in GHC, but they've always been fixed so far, so hopefully someone here will be familiar with what is causing this one! Please let me know if there is further information I can provide. The file in question looks basically like this: (it depends on some other stuff in our project, and so it won't build immediately if you paste it onto your machine; let me know if you need me to bundle it up into something self-contained). {{{#!hs -- | A bespoke record/HList type. 'el' interprets fields into types; 'tot' is -- the maximal extension of the record type; and 'rs' is the subset of 'tot' -- contained in the record itself. data Record (el :: k -> *) (tot :: [k]) (rs :: [k]) where Nil :: Record el tot '[] (:*) :: ( ElemTF r tot ?? '("the key", r, "is not permitted in this record, which may only contain", tot) , DistinctTF (r ': rs) ?? '("the key", r, "is already in", rs) ) => el r -> Record el tot rs -> Record el tot (r ': rs) infixr 9 :* -- | Records have lenses for their fields. class ElemTF r rs ~ True => RLens rs r where rlens :: proxy r -> CL.Lens' (Record el tot rs) (el r) instance RLens (r ': rs) r where rlens _ = CL.lens (\(x :* _) -> x) (\(_ :* xs) x -> x :* xs) instance (ElemTF r (s ': rs) ~ True, RLens rs r) => RLens (s ': rs) r where rlens _ = CL.lens (\(_ :* xs) -> xs ^. rlens Proxy) (\(x :* xs) y -> x :* xs & rlens Proxy .~ y) -- | Records with fields in 'K' give rise to a functor from 'Hask^K' to 'Hask'. (<<$>>) :: (forall x. f x -> g x) -> Record f tot rs -> Record g tot rs _ <<$>> Nil = Nil eta <<$>> (x :* xs) = eta x :* (eta <<$>> xs) infixl 8 <<$>> -- | Records can be traversed to pull out some of their effects. rtraverse :: Applicative h => (forall x. f x -> h (g x)) -> Record f tot rs -> h (Record g tot rs) rtraverse _ Nil = pure Nil rtraverse f (x :* xs) = (:*) <$> f x <*> rtraverse f xs -- | As a special case, we can yank out the first layer of effects in a -- composed functor stack. rtraverse1 :: Applicative f => Record (f :. g) tot rs -> f (Record g tot rs) rtraverse1 = rtraverse getCompose -- | Records whose fields are uniform in type may be turned into a list. recordToList :: Record (Const t) tbl rs -> [t] recordToList Nil = [] recordToList (Const x :* xs) = x : recordToList xs instance Show (Record el tot '[]) where show _ = "Nil" instance ( Show (Record el tot rs) , Show (el r) ) => Show (Record el tot (r ': rs)) where show (x :* xs) = "(" ++ show x ++ " :* " ++ show xs ++ ")" data family Sing (a :: k) class SingI a where sing :: Sing a class kparam ~ Any => SingE (kparam :: k) rep | kparam -> rep where fromSing :: Sing (a :: k) -> rep }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9584> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 10

[GHC] #8122: make binary-dist broken on OS X in HEAD
by GHC 26 May '15

26 May '15

#8122: make binary-dist broken on OS X in HEAD --------------------------------+------------------------------------------ Reporter: danharaj | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 7.7 Keywords: | Operating System: MacOS X Architecture: x86_64 | Type of failure: Installing GHC failed (amd64) | Test Case: Difficulty: Unknown | Blocking: Blocked By: | Related Tickets: | --------------------------------+------------------------------------------ After a successful configure and make, make binary-dist fails: {{{ ➜ ghc git:(master) make ===--- building phase 0 make -r --no-print-directory -f ghc.mk phase=0 phase_0_builds make[1]: Nothing to be done for `phase_0_builds'. ===--- building phase 1 make -r --no-print-directory -f ghc.mk phase=1 phase_1_builds make[1]: Nothing to be done for `phase_1_builds'. ===--- building final phase make -r --no-print-directory -f ghc.mk phase=final all make[1]: Nothing to be done for `all'. ➜ ghc git:(master) make binary-dist rm -f bindist-list make -r --no-print-directory -f ghc.mk bindist BINDIST=YES "cp" -p ghc/stage1/build/tmp/ inplace/lib/bin/ghc-stage1 cp: ghc/stage1/build/tmp/ is a directory (not copied). make[1]: *** [inplace/lib/bin/ghc-stage1] Error 1 make: *** [binary-dist-prep] Error 2 }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8122> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 12