GHCi doesn't load project.

I got the following output when trying to load my Haskell project into GHCi using stack:

GHCi, version 8.2.2: http://www.haskell.org/ghc/  :? for help
ghc: panic! (the 'impossible' happened)
  (GHC version 8.2.2 for x86_64-unknown-linux):
	Loading temp shared object failed: /tmp/ghc3372_0/libghc_13.so: undefined symbol: numStates_g

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

No other informative output was displayed. Output says report the defect, so you get a "bug report."

Trac metadata

Trac field	Value
Version	8.2.2
Type	Bug
TypeOfFailure	OtherFailure
Priority	normal
Resolution	Unresolved
Component	GHCi
Test case
Differential revisions
BlockedBy
Related
Blocking
CC
Operating system
Architecture

mentioned in issue #13786 (closed)

changed weight to 5

added GHCi Tbug Trac import labels

Are you by any chance missing a foreign library reference in your cabal file? Is there some way I can reproduce this?

You can clone the project here:

https://github.com/amnh/pcg

To replicate run:

$ git clone https://github.com/amnh/PCG
$ cd PCG
$ stack build && stack ghci

The project is so large I have no idea where the code inducing this the defect might lie. It compiles fine, but I haven't been able to use the GHCi interpreter for over a year. Getting pretty annoying at this point. Seriously hampers prototyping new functionality.

changed milestone to %8.6.1

changed weight to 7

It looks like the issue here is that GHC is trying to load the temporary Haskell objects before it loads the C objects. In GHC's defense, Cabal does list the C objects after the modules in the command line that it produces. It seems to me like GHC should likely first load any C objects, then compile and load the Haskell modules requested.

Trac metadata

Trac field	Value
Priority	normal → high

I'm having a look at this. I've got it reproducing locally with commit 6f1dfdf1513d7c6c55bc63606711c90643bf4dc4 from that repository, and I'm just trying to cut it down to a smaller GHC-only example.

Note that numStates_g is declared extern in ukkCheckPoint.c via ukkCommon.h, and is actually defined in ukkCommon.c. If we inspect the command line passed to GHC, we see that ukkCheckPoint.o appears before ukkCommon.o. Reducing to a tiny example, we can reproduce the bug:

$ cat a.c
int numStates_g = 42;
$ cat b.c
extern int numStates_g;

int foo(int a) {
  return a + numStates_g;
}
$ gcc -c a.c
$ gcc -c b.c
$ ghc --interactive a.o b.o
GHCi, version 8.4.2: http://www.haskell.org/ghc/  :? for help
Prelude> :q
Leaving GHCi.
$ ghc --interactive b.o a.o
GHCi, version 8.4.2: http://www.haskell.org/ghc/  :? for help
ghc: panic! (the 'impossible' happened)
  (GHC version 8.4.2 for i386-unknown-linux):
	Loading temp shared object failed: /tmp/ghc12016_0/libghc_1.so: undefined symbol: numStates_g

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

So GHCi is sensitive to the ordering of .o files passed on the command line. This is already known as #13786 (closed), so I guess this issue's a duplicate.

I've verified that the reproduction repo works with GHCi if the definitions are moved into ukkCheckPoint.c, which is a work-around.

closed

Trac metadata

Trac field	Value
Resolution	Unresolved → ResolvedDuplicate

added Phigh label