ghci gives ghc panic when using foreign c calls

Question

I'm trying to use ghci / stack repl on a project where one module has foreign calls linked to a C lib tdsodbc, but I keep getting

ghc: panic! (the 'impossible' happened)
  (GHC version 7.10.3 for x86_64-unknown-linux):
    Loading temp shared object failed: /tmp/ghc4628_0/libghc_71.so: undefined symbol: SQLPrepareW

(where SQLPrepareW is defined in that C lib). Building with stack works fine. This happens even on other modules that just happen to import the foreign-calling module, even without actually calling the foreign functions. It doesn't happen on load, but as soon as I try to fully evaluate any function in the repl.

How can I tell ghci that some of the functions are defined in libs outside of ghc?

I've tried the -l option (e.g. stack exec ghci -- -ltdsodbc), but the only difference then is that a different function from the same lib is in the error message:

ghc: panic! (the 'impossible' happened)
  (GHC version 7.10.3 for x86_64-unknown-linux):
        Loading temp shared object failed: /tmp/ghc24107_0/libghc_25.so: undefined symbol: SQLDriverConnectW

Note that it's obviously checking for the lib when using -l, since if I misspell it, it'll say it can't find it:

$ stack exec ghci -- -L/usr/lib/x86_64-linux-gnu/odbc  -ltdsodbctypo
Warning (added by new or init): Specified resolver could not satisfy all dependencies. Some external packages have been added as dependencies.
You can suppress this message by removing it from stack.yaml

GHCi, version 7.10.3: http://www.haskell.org/ghc/  :? for help
<command line>: user specified .o/.so/.DLL could not be loaded (libtdsodbctypo.so: cannot open shared object file: No such file or directory)
Whilst trying to load:  (dynamic) tdsodbctypo
Additional directories searched:   /usr/lib/x86_64-linux-gnu/odbc

This is with

$ stack --version
Version 1.4.0, Git revision e714f1dd3fade19496d91bd6a017e435a96a6bcd (4640 commits) x86_64 hpack-0.17.0

I've also tried stack ghci --ghci-options '-ltdsodbc -fobject-code', but it also panics with undefined symbol: SQLPrepareW.

ah, that looked so promising, I did earlier have some modules missing from other-modules, but even after adding and doing stack clean && stack build && stack ghci it still panics just as before :( — unhammer
$ nm libtdsodbc.so␍ nm: libtdsodbc.so: no symbols but $ strings libtdsodbc.so|grep SQLDriverConnectW␍ SQLDriverConnectW (and it compiles and runs fine with ghc, just not in ghci) — unhammer

unhammer unhammer · Accepted Answer · 2017-06-23T07:43:28

The nice folks in #haskell on freenode said maybe I should try passing -fobject-code to ghci. That didn't work. I tried :set and :seti to see if it was already set, but ghci didn't show anything about object code. (Doing :unset -fobject-code just gave Some flags have not been recognized: -fno-object-code.)

Then today I happened to look at my ~/.ghci for some other reason, and that did have :set -fobject-code, even though :set/:seti doesn't show that. Removing :set -fobject-code from my ~/.ghci took away the panic attacks, and I can now use functions from modules that import the module that defines foreign functions :)

Actually calling any of the foreign functions from ghci leads to a segfault (catchsegv log for the interested), but at least I can test the pure stuff now …

ghci gives ghc panic when using foreign c calls

1 Answers