GHCi doesn't work: unknown symbol `__gmpn_rshift'

[thomie]

Using the same build as reported in #240, I'm getting the following error when trying to start ghci:

$ inplace/bin/ghc-stage2 --interactive
GHCi, version 8.1.20160508: http://www.haskell.org/ghc/  :? for help
ghc-stage2: /home/thomas/ghc-hadrian/_build/stage1/libraries/integer-gmp/HSinteger-gmp-1.0.0.1.o: unknown symbol `__gmpn_rshift'
ghc-stage2: unable to load package `integer-gmp-1.0.0.1'

(as reported in #240, my build didn't finish, but ghc-stage2 exists, so I think ghci should work regardless)

The __gmpn_rshift issue has come up before:

• https://mail.haskell.org/pipermail/ghc-devs/2014-November/007388.html
• https://mail.haskell.org/pipermail/ghc-devs/2014-December/007528.html
• https://ghc.haskell.org/trac/ghc/ticket/9856

[snowleopard]

Yes, this is also reproducible on my machine.

I don't think we could ever run ghci. My understanding was that it is tied very tightly to the dynamic way which is not yet implemented (#4). However, maybe I'm wrong and we should be able to run ghci when building plain vanilla GHC?

[thomie]

I did a build using the old build system, using a mk/build.mk file which should closely resemble --flavour=quick:

include mk/flavours/quickest.mk
GhcStage1HcOpts    = -O0
GhcLibWays = v
DYNAMIC_GHC_PROGRAMS = NO

ghci works with this build. GHC's .travis.yml also sets DYNAMIC_GHC_PROGRAMS = NO, and it passes all ghci tests.

[snowleopard]

@thomie Thanks, good to know this does not depend on #4.

[thoughtpolice]

Yes, GHCi definitely is supported, and we only switched to dynamic linking in 7.8. Before that we used GHC's own home-grown linker, and in fact, every time you use Windows, you use the built in static linker.

[snowleopard]

So, I found the cause: Hadrian incorrectly builds HSinteger-gmp-1.0.0.1.o library. When I rebuild GHC using the correct library (built by the Make build system), GHCi works fine.