May 2013 - ghc-tickets

Re: [GHC] #6063: GHC's build-time ld-flag checks are problematic
by GHC 04 May '13

04 May '13

#6063: GHC's build-time ld-flag checks are problematic ---------------------------------+------------------------------------------ Reporter: parcs | Owner: thoughtpolice Type: bug | Status: patch Priority: high | Milestone: 7.8.1 Component: Compiler | Version: 7.4.1 Keywords: | Os: Linux Architecture: Unknown/Multiple | Failure: GHC doesn't work at all Difficulty: Unknown | Testcase: Blockedby: | Blocking: Related: #4862 | ---------------------------------+------------------------------------------ Comment(by thoughtpolice): Updated per review comments (thanks to int-e on freenode as well.) -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/6063#comment:15> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #6063: GHC's build-time ld-flag checks are problematic
by GHC 04 May '13

04 May '13

#6063: GHC's build-time ld-flag checks are problematic ---------------------------------+------------------------------------------ Reporter: parcs | Owner: thoughtpolice Type: bug | Status: patch Priority: high | Milestone: 7.8.1 Component: Compiler | Version: 7.4.1 Keywords: | Os: Linux Architecture: Unknown/Multiple | Failure: GHC doesn't work at all Difficulty: Unknown | Testcase: Blockedby: | Blocking: Related: #4862 | ---------------------------------+------------------------------------------ Comment(by parcs): I notice two things: 1. From what I can tell, you don't need to spawn the linker process when `os` is `OSDarwin` or `OSMinGW32`. 2. Use `hang` to print the error message: {{{ hang (text "Warning:") 9 $ text "Couldn't ..." $$ text "Make ..." }}} -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/6063#comment:14> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #6063: GHC's build-time ld-flag checks are problematic
by GHC 04 May '13

04 May '13

#6063: GHC's build-time ld-flag checks are problematic ---------------------------------+------------------------------------------ Reporter: parcs | Owner: thoughtpolice Type: bug | Status: patch Priority: high | Milestone: 7.8.1 Component: Compiler | Version: 7.4.1 Keywords: | Os: Linux Architecture: Unknown/Multiple | Failure: GHC doesn't work at all Difficulty: Unknown | Testcase: Blockedby: | Blocking: Related: #4862 | ---------------------------------+------------------------------------------ Changes (by thoughtpolice): * status: new => patch -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/6063#comment:13> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #6063: GHC's build-time ld-flag checks are problematic
by GHC 04 May '13

04 May '13

#6063: GHC's build-time ld-flag checks are problematic ---------------------------------+------------------------------------------ Reporter: parcs | Owner: thoughtpolice Type: bug | Status: new Priority: high | Milestone: 7.8.1 Component: Compiler | Version: 7.4.1 Keywords: | Os: Linux Architecture: Unknown/Multiple | Failure: GHC doesn't work at all Difficulty: Unknown | Testcase: Blockedby: | Blocking: Related: #4862 | ---------------------------------+------------------------------------------ Comment(by thoughtpolice): I have a patch for this now. I decided to generalize it a little and added functionality to generally detect linker information at runtime, and distinguish between several cases. I have verified it works and am validating on my Mac OS X machine and my other Linux machines. I will set up a Windows machine as well. I'd like some code review before I push this patch to the tree directly. If Ian or anyone else would like to give feedback, please do so. If there aren't any complaints I'll push this myself. @nh2 - no, this was not fixed in that work. The issue is a little more complicated. Please see my commit message and patch which details the issue fairly clearly. {{{ commit e1825358b318f847aca19a230fb0a4377830d767 Author: Austin Seipp <aseipp(a)pobox.com> Date: Sat May 4 16:07:22 2013 -0500 Detect linker information at runtime. Fixes Trac #6063 Previously, we did ./configure time checks to see if 'GNU ld' supported certain options. If it does, we bake those options into the link step. See Trac #5240. Ergo, this is a build-time configuration. Unfortunately, the linker we use at runtime can change for several reasons. One is that the user specifies -pgml 'foo'. The other is if /usr/bin/ld or whatnot literally *changes* from when GHC was built. Obviously, not every linker supports these options, like GNU gold, and that would lead to linking failure. This is Trac #6063. What this ultimately means is that we need to check at runtime what linker we're using. Always. This is actually a little bit complicated because we normally use the C compiler as our linker. Also, OS X does not support gold OR ld, Windows only has GNU ld, etc. Finally, this patch also unconditionally gives '--hash-size=31' and '--reduce-memory-overheads' to the system linker if it's GNU ld. These options have been supported for 8+ years from what I can see, and there are probably a lot of *other* reasons why GHC would not work with such an ancient binutils, all things considered. See Note [Run-time linker info] in SysTools for more details. There are plenty of comments as well in the surrounding code. Signed-off-by: Austin Seipp <aseipp(a)pobox.com> }}} -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/6063#comment:12> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #6063: GHC's build-time ld-flag checks are problematic
by GHC 04 May '13

04 May '13

#6063: GHC's build-time ld-flag checks are problematic ---------------------------------+------------------------------------------ Reporter: parcs | Owner: thoughtpolice Type: bug | Status: new Priority: high | Milestone: 7.8.1 Component: Compiler | Version: 7.4.1 Keywords: | Os: Linux Architecture: Unknown/Multiple | Failure: GHC doesn't work at all Difficulty: Unknown | Testcase: Blockedby: | Blocking: Related: #4862 | ---------------------------------+------------------------------------------ Comment(by nh2): @jlebar That's not so easy, but you could actually make it *use* gold. See here: http://stackoverflow.com/questions/6952396/why-does-ghc-take-so- long-to-link/16105691#16105691. Might also contain some other relevant info for you (e.g. that -pgml is actually gcc, so you'd have to tell gcc which linker it should call, and I guess that's why your env variable doesn't work). -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/6063#comment:11> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #6063: GHC's build-time ld-flag checks are problematic
by GHC 04 May '13

04 May '13

#6063: GHC's build-time ld-flag checks are problematic ---------------------------------+------------------------------------------ Reporter: parcs | Owner: thoughtpolice Type: bug | Status: new Priority: high | Milestone: 7.8.1 Component: Compiler | Version: 7.4.1 Keywords: | Os: Linux Architecture: Unknown/Multiple | Failure: GHC doesn't work at all Difficulty: Unknown | Testcase: Blockedby: | Blocking: Related: #4862 | ---------------------------------+------------------------------------------ Comment(by jlebar): Is there a way to work around this in the meantime, short of uninstalling gold? I tried running # LD=ld.bfd cabal install ... and that didn't work. -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/6063#comment:10> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #7886: data command does not work on WinGHCi
by GHC 04 May '13

04 May '13

#7886: data command does not work on WinGHCi -------------------------+-------------------------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 7.4.2 | Keywords: Os: Windows | Architecture: Unknown/Multiple Failure: None/Unknown | Blockedby: Blocking: | Related: -------------------------+-------------------------------------------------- An error is obtained when defining a new data type in WinGHCi with the data command. {{{ data List a = Empty | Cons a (List a) deriving (show) }}} The error is as follows. {{{ ghc: panic! (the 'impossible' happened) (GHC version 7.4.2 for i386-unknown-mingw32): nameModule show{tv aC4} Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7886> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

[GHC] #7880: Require "forall" in definitions of polymorphic types
by GHC 03 May '13

03 May '13

#7880: Require "forall" in definitions of polymorphic types ----------------------------------------+----------------------------------- Reporter: monoidal | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 7.6.3 | Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: GHC accepts invalid program | Blockedby: Blocking: | Related: ----------------------------------------+----------------------------------- With rank-n-types, we can write {{{ data T1 = T (() => a) type T2 = () => a }}} but {{{ data T1' = T' a type T2' = a }}} gives an error. I think this behavior is very odd. I propose the following simple rule: such variables in type and data declarations should never be implicitly quantified; i.e. they have to be introduced using "forall". Since above types require RankNTypes anyway, there is little harm in requiring "forall", and in my opinion it's good to inform the reader that a type uses universal quantification. More complicated example, from lens: {{{ type Traversal s t a b = forall f. Applicative f => (a -> f b) -> s -> f t }}} By the way, GHC's documentation is outdated regarding this issue: http://www.haskell.org/ghc/docs/7.6.3/html/users_guide/other-type- extensions.html point 7.12.5.1. states that "`data T a = MkT (Either a b) (b -> b)`" is equivalent to "`data T a = MkT (forall b. Either a b) (forall b. b -> b)`" - since at least GHC 7.2 the former gives an error. -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7880> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

Re: [GHC] #7373: When building GHC: Failed to load interface for `GHC.Fingerprint'
by GHC 03 May '13

03 May '13

#7373: When building GHC: Failed to load interface for `GHC.Fingerprint' -------------------------------+-------------------------------------------- Reporter: igloo | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.8.1 Component: libraries/base | Version: 7.6.1 Resolution: | Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: None/Unknown | Difficulty: Unknown Testcase: | Blockedby: Blocking: | Related: -------------------------------+-------------------------------------------- Comment(by simonpj): Hmm. I still don't get it. Y.hi will not expect X.hi to exist. So Z, which imports Y.hi, won't expect X.hi to exist either, will it? It'll just look in X.hi-boot. -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7373#comment:6> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7373: When building GHC: Failed to load interface for `GHC.Fingerprint'
by GHC 03 May '13

03 May '13

#7373: When building GHC: Failed to load interface for `GHC.Fingerprint' -------------------------------+-------------------------------------------- Reporter: igloo | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.8.1 Component: libraries/base | Version: 7.6.1 Resolution: | Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: None/Unknown | Difficulty: Unknown Testcase: | Blockedby: Blocking: | Related: -------------------------------+-------------------------------------------- Changes (by igloo): * owner: igloo => * status: closed => new * resolution: wontfix => Comment: No, our build system doesn't build the modules in package order. For example, it might build `directory:System.Directory` before `base:Control.Arrow` (assuming `System.Directory` doesn't transitively import `Control.Arrow`). This removes a load of dependencies, so makes the build more parallelisable. If I remember correctly, the problem in this ticket was that we have something like: {{{ Package a: X imports Y and Y imports X-boot. Package b: Z imports Y (from package a) }}} and an inlining in Y refers to `X.x`. We compile X-boot, then Y, then Z. When compiling Z, we expect X.hi to exist, and look in it to see if there's an inlining for `x`. -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7373#comment:5> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0