GHC panic when compiling compdata

When testing ghc-7.8.2.20140609 with Stackage, I came across the following ghc panic:

[51 of 62] Compiling Data.Comp.Ordering ( src/Data/Comp/Ordering.hs, dist/build/Data/Comp/Ordering.o )
ghc: panic! (the 'impossible' happened)
  (GHC version 7.8.2.20140609 for x86_64-unknown-linux):
    Loading temp shared object failed: /tmp/ghc4836_0/ghc4836_257.so: undefined symbol: compdatazm0zi8zi1zi0_DataziCompziDeriveziUtils_zdwabstractConType_info

Please report this as a GHC bug:  http://www.haskell.org/ghc/reportabug

Failed to install compdata-0.8.1.0

mentioned in issue #8935 (closed)

changed milestone to %7.8.3

changed weight to 5

added Tbug Trac import labels

Attached file compdata.log (download).

changed weight to 10

Did this happen with 7.8.2? It might be a regression with the linker changes.

Trac metadata

Trac field	Value
Priority	normal → highest

That's right, I asked Michael to file this, I just haven't had time to get to it yet (I've been in merge limbo for the past two days with some of the latest patches, so I may drop some of them at this point).

Hmm, I was unable to reproduce this with the latest 7.8 commit 32b4bf33. Strange since I assume that's very similar if not identical to your GHC version 7.8.2.20140609.

Fwiw, I can confirm this with the current ghc-7.8.3 PPA .deb which is supposed to correspond to 32b4bf33

Fwiw, ghc-7.8.3-7.8.2.20140609-1 reports the wrong version (7.8.2.20140603) due to a stale VERSION file in the tharball, that's supposed to be fixed by ghc-7.8.3-7.8.2.20140609-2 which is building right now

moreover, Simon suggested on #ghc that

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

changed the description

I also can't reproduce with 32b4bf33 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?

I just built GHC myself with the same commit (32b4bf33) and experienced the same problem with compdata.

Replying to [ticket:9186#comment:84000 snoyberg]:

I just built GHC myself with the same commit (32b4bf33) and experienced the same 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?

I've reproduced the same error whether I use cabal install or cabal install -j. I did the building in a fresh hsenv with a standard cabal config file: http://lpaste.net/105744. I got the same issues from:

1. The build I just made.
2. Herbert's Ubuntu PPA.
3. A binary that Austin sent me.

I'm running Ubuntu 12.04, 64-bit. I got the same results on my Stackage server as well: http://jenkins.stackage.org/job/Stackage/36/ghcversion=7.8.3/console.

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.

Yes, this bug is particularly weird because on e.g. my Debian machine where I cook the release images, this does not happen. But it does on Ubuntu 12.04.

I have a potential fix incoming with a binary build people should test.

OK, this is quite annoying, it consistently fails when I do cabal install -v, but consistently succeeds when I do cabal install -v3!