#14713: GHCi doesn't load project. -------------------------------------+------------------------------------- Reporter: recursion-ninja | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 8.2.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: x86_64 | (amd64) Type of failure: GHCi crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): Are you by any chance missing a foreign library reference in your cabal file? Is there some way I can reproduce this? -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/14713#comment:1 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#14713: GHCi doesn't load project. -------------------------------------+------------------------------------- Reporter: recursion-ninja | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.6.1 Component: GHCi | Version: 8.2.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: x86_64 | (amd64) Type of failure: GHCi crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * priority: normal => high * milestone: => 8.6.1 Comment: 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. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/14713#comment:3 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#14713: GHCi doesn't load project. -------------------------------------+------------------------------------- Reporter: recursion-ninja | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.6.1 Component: GHCi | Version: 8.2.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: x86_64 | (amd64) Type of failure: GHCi crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by quasicomputational): 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, 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. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/14713#comment:5 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler