#9186: GHC panic when compiling compdata -------------------------------------+------------------------------------ Reporter: snoyberg | Owner: Type: bug | Status: new Priority: highest | Milestone: 7.8.3 Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by simonmar): * priority: normal => highest Comment: Did this happen with 7.8.2? It might be a regression with the linker changes. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/9186#comment:1 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#9186: GHC panic when compiling compdata -------------------------------------+------------------------------------ Reporter: snoyberg | Owner: Type: bug | Status: new Priority: highest | Milestone: 7.8.3 Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by rwbarton): Hmm, I was unable to reproduce this with the latest 7.8 commit 32b4bf33989bdda4dffed1866f7a61a7da4ca275. Strange since I assume that's very similar if not identical to your GHC version 7.8.2.20140609. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/9186#comment:3 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#9186: GHC panic when compiling compdata -------------------------------------+------------------------------------ Reporter: snoyberg | Owner: Type: bug | Status: new Priority: highest | Milestone: 7.8.3 Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by hvr): moreover, Simon suggested on `#ghc` that

if #9186 is a regression, it is almost certainly caused by 2f8b4c9330b455d4cb31c186c747a7db12a69251, but it's probably best to just back that out if it's the last thing holding up the release

-- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/9186#comment:5 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#9186: GHC panic when compiling compdata -------------------------------------+------------------------------------ Reporter: snoyberg | Owner: Type: bug | Status: new Priority: highest | Milestone: 7.8.3 Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by juhpetersen): I also can't reproduce with 32b4bf33989bdda4dffed1866f7a61a7da4ca275 on Fedora, with a snapshot I built last week: http://copr-be.cloud.fedoraproject.org/results/petersen/ghc-7.8/fedora- rawhide-x86_64/ghc-7.8.3-36.2.fc20/ Are you still seeing this, Michael? Is anyone running 32bit? -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/9186#comment:7 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

I just built GHC myself with the same commit (32b4bf33989bdda4dffed1866f7a61a7da4ca275) and experienced the same

#9186: GHC panic when compiling compdata -------------------------------------+------------------------------------ Reporter: snoyberg | Owner: Type: bug | Status: new Priority: highest | Milestone: 7.8.3 Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by rwbarton): Replying to [comment:8 snoyberg]: problem with compdata. What steps exactly are you taking to encounter this error? Can you paste your relevant Cabal configuration? Are you using `-j` for either cabal- install or ghc? Also, I wonder if we could be seeing different behavior from the system linker. What distribution/version are you running? -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/9186#comment:9 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#9186: GHC panic when compiling compdata -------------------------------------+------------------------------------ Reporter: snoyberg | Owner: Type: bug | Status: new Priority: highest | Milestone: 7.8.3 Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by rwbarton): OK, I repeated my steps (as far as I can tell) on an Ubuntu 12.04 VM and now I do get the error. Curious. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/9186#comment:11 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#9186: GHC panic when compiling compdata -------------------------------------+------------------------------------ Reporter: snoyberg | Owner: Type: bug | Status: new Priority: highest | Milestone: 7.8.3 Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by rwbarton): OK, this is quite annoying, it consistently fails when I do `cabal install -v`, but consistently succeeds when I do `cabal install -v3`! -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/9186#comment:13 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#9186: GHC panic when compiling compdata -------------------------------------+------------------------------------ Reporter: snoyberg | Owner: Type: bug | Status: closed Priority: highest | Milestone: 7.8.3 Component: Compiler | Version: 7.8.2 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: #8935 -------------------------------------+------------------------------------ Comment (by snoyberg): I can confirm that reverting that commit solves the problem on my system. I'll proceed with trying a new Stackage build. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/9186#comment:15 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#9186: GHC panic when compiling compdata -------------------------------------+------------------------------------ Reporter: snoyberg | Owner: simonmar Type: bug | Status: new Priority: highest | Milestone: 7.8.4 Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: #8935 -------------------------------------+------------------------------------ Changes (by simonpj): * owner: => simonmar Comment: Back story: bug in runtime linker, introduced between 7.6 and 7.8 during dynamic linking changes. Fixing this changed the way we link dynamic libraries. But that introduced some other bug. Simon M will investigate. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/9186#comment:17 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#9186: GHC panic when compiling compdata -------------------------------------+------------------------------------- Reporter: snoyberg | Owner: simonmar Type: bug | Status: new Priority: high | Milestone: 7.8.4 Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: #8935 Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thoughtpolice): * priority: highest => high -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/9186#comment:19 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#9186: GHC panic when compiling compdata -------------------------------------+------------------------------------- Reporter: snoyberg | Owner: simonmar Type: bug | Status: new Priority: high | Milestone: 7.8.4 Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: #8935 Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by carter): Is this a linux only bug? I just built compdata-0.9 in a sandbox on my mac and I didn't encounter this problem. I used my own build of GHC 7.8.3 on OS X 10.9 Has anyone reproduced this issue on linux with GHC 7.8.3? -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/9186#comment:21 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

OK, this is quite annoying, it consistently fails when I do `cabal install -v`, but consistently succeeds when I do `cabal install -v3`! So with more verbose output you could build compdata. That you could do so consistently looks promising. Perhaps I missed laziness somewhere in my

#9186: GHC panic when compiling compdata -------------------------------------+------------------------------------- Reporter: snoyberg | Owner: simonmar Type: bug | Status: new Priority: high | Milestone: 7.8.4 Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: #8935 Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by trommler): Replying to [comment:13 rwbarton]: patch for #8935. I'll go check. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/9186#comment:23 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#9186: GHC panic when compiling compdata -------------------------------------+------------------------------------- Reporter: snoyberg | Owner: simonmar Type: bug | Status: new Priority: high | Milestone: 7.10.1 Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: #8935 Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by trommler): Replying to [comment:24 trommler]:

...

I rebased the patch for #8935 and cannot reproduce the issue for compdata version 0.8.1.0 and 0.9. I also built Haskell Platform [https://build.opensuse.org/project/show/devel:languages:haskell:platform] and pandoc [https://build.opensuse.org/project/show/devel:languages:haskell:pandoc] on OBS and did not see the issue. Setting environment variable `SUSE_ASNEEDED=1` I can reproduce the bug. That environment variable changes the behaviour of the link editor to include the flag `--as-neeeded` in the link command.

From man ld(1): --as-needed --no-as-needed This option affects ELF DT_NEEDED tags for dynamic libraries mentioned on the command line after the --as-needed option. Normally the linker will add a DT_NEEDED tag for each dynamic library mentioned on the command line, regardless of whether the library is actually needed or not. --as-needed causes a DT_NEEDED tag to only be emitted for a library that satisfies an undefined symbol reference from a regular object file or, if the library is not found in the DT_NEEDED lists of other libraries linked up to that point, an undefined symbol reference from another dynamic library. --no-as-needed restores the default behaviour. The important point here is: The order of the linker arguments does matter! I do not understand, however, what adding -v3 changes (see [comment:13 @rwbarton's comment]) to make the build go through. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/9186#comment:26 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#9186: GHC panic when compiling compdata -------------------------------------+------------------------------------- Reporter: snoyberg | Owner: simonmar Type: bug | Status: patch Priority: high | Milestone: 7.10.1 Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: #8935 Test Case: | Blocking: | Differential Revisions: Phab:D349 | -------------------------------------+------------------------------------- Changes (by thomie): * differential: D349 => Phab:D349 -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/9186#comment:28 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#9186: GHC panic when compiling compdata -------------------------------------+------------------------------------- Reporter: snoyberg | Owner: simonmar Type: bug | Status: patch Priority: high | Milestone: 7.10.1 Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: #8935 Test Case: | Blocking: | Differential Revisions: Phab:D349 | -------------------------------------+------------------------------------- Comment (by Austin Seipp ): In [changeset:"383733b9191a36e2d3f757700842dbc3855911d9/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="383733b9191a36e2d3f757700842dbc3855911d9" Fix obscure problem with using the system linker (#8935) Summary: In a statically linked GHCi symbol `environ` resolves to NULL when called from a Haskell script. When resolving symbols in a Haskell script we need to search the executable program and its dependent (DT_NEEDED) shared libraries first and then search the loaded libraries. We want to be able to override functions in loaded libraries later. Libraries must be opened with local scope (RTLD_LOCAL) and not global. The latter adds all symbols to the executable program's symbols where they are then searched in loading order. We want reverse loading order. When libraries are loaded with local scope the dynamic linker cannot use symbols in that library when resolving the dependencies in another shared library. This changes the way files compiled to object code must be linked into temporary shared libraries. We link with the last temporary shared library created so far if it exists. Since each temporary shared library is linked to the previous temporary shared library the dynamic linker finds the latest definition of a symbol by following the dependency chain. See also Note [RTLD_LOCAL] for a summary of the problem and solution. Cherry-picked commit 2f8b4c Changed linker argument ordering On some ELF systems GNU ld (and others?) default to --as-needed and the order of libraries in the link matters. The last temporary shared library, must appear before all other libraries. Switching the position of extra_ld_inputs and lib_path_objs does that. Fixes #8935 and #9186 Reviewers: austin, hvr, rwbarton, simonmar Reviewed By: simonmar Subscribers: thomie, carter, simonmar Differential Revision: https://phabricator.haskell.org/D349 GHC Trac Issues: #8935, #9186, #9480 }}} -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/9186#comment:30 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler