#8276: Building Haddock documentation panics with perf build on x86_64 Linux ---------------------------------------+---------------------------------- Reporter: jstolarek | Owner: Type: bug | Status: new Priority: high | Milestone: Component: Documentation | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: x86_64 (amd64) Type of failure: Compile-time crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ---------------------------------------+---------------------------------- Comment (by simonmar): Wow, we've got ourselves into a real mess here. There's a lot that I don't understand about all this saving/restoring of static flags stuff, but I count at least three separate bugs. Bug 1: the Haddock panic that started this ticket. Why is Haddock saving and restoring the static flag settings? I can't even see how that would work, because we have CAFs that depend on the static flag settings (like `opt_PprStyle_debug`) and those can't be saved/restored. But in any case, making the static flags empty is causing the panic in `staticFlags` to trigger. I'm not clear on why we're calling `withGhc` twice in Haddock, and parsing all the flags twice etc. Bug 2: When GHCi is dynamically linked and you load the `ghc` package, you are getting the same `ghc` package that GHCi itself is using, which is why the static flags are already set. This is a serious problem, because it means that we can't have separate static flags when using the `ghc` package from GHCi. Bug 3: I also noticed `CoreMonad.reinitializeGlobals` while I was perusing the code. That is needed when we're doing static linking (two `ghc` packages) but not when we're doing dynamic linking (one `ghc` package). Shouldn't there be some logic to test that somewhere? -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8276#comment:20 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler