hls fails with linker error due to missing symbols (with ghc linked dinamically)

[merijn]

When trying to use ghcide in my codebase I run into a weird linker issue where Haskell symbols can't be loaded because libc symbols they refer to are missing, as per the following error:

ghcide: /home/mverstra/.cabal/store/ghc-8.6.5/persistent-sqlite-2.10.6.2-7f73d67da3642575ea84da1a97de2359947f3009597095d9e4a57c670f242398/lib/libHSpersistent-sqlite-2.10.6.2-7f73d67da3642575ea84da1a97de2359947f3009597095d9e4a57c670f242398.a: unknown symbol `stat64'
ghcide: /home/mverstra/.cabal/store/ghc-8.6.5/persistent-sqlite-2.10.6.2-7f73d67da3642575ea84da1a97de2359947f3009597095d9e4a57c670f242398/lib/libHSpersistent-sqlite-2.10.6.2-7f73d67da3642575ea84da1a97de2359947f3009597095d9e4a57c670f242398.a: unknown symbol `sqlite3_errmsg'
ghcide: ^^ Could not load 'persistentzmsqlitezm2zi10zi6zi2zm7f73d67da3642575ea84da1a97de2359947f3009597095d9e4a57c670f242398_DatabaseziSqlite_zdfShowError_closure', dependency unresolved. See top entry above.

File:     /home/mverstra/gpu/benchmark-analysis/src/Schema/Implementation.hs
Hidden:   no
Range:    1:0-100001:0
Source:   typecheck
Severity: DsError
Message:
  Program error:
  ByteCodeLink.lookupCE
  During interactive linking, GHCi couldn't find the following symbol:
  persistentzmsqlitezm2zi10zi6zi2zm7f73d67da3642575ea84da1a97de2359947f3009597095d9e4a57c670f242398_DatabaseziSqlite_zdfShowError_closure
  This may be due to you not asking GHCi to load extra object files,
  archives or DLLs needed by your current session. Restart GHCi, specifying
  the missing library using the -L/path/to/object/dir and -lmissinglibname
  flags, or simply by naming the relevant files on the GHCi command line.
  Alternatively, this link failure might indicate a bug in GHCi.
  If you suspect the latter, please send a bug report to:
  glasgow-haskell-bugs@haskell.org

I've tried to debug this further, but I keep getting stuck. The codebase where it goes wrong can be found here: https://github.com/merijn/Belewitte

The C++ parts of the repo aren't relevant to Haskell code or error, running make in the benchmark-analysis directory is sufficient to build the Haskell bits of the repo. The code/makefile assumes GHC 8.6.5 and cabal-install >2.4. It can be build with GHC 8.10.1 too, if the Config.mk is edited to have PROJECTFILE:=cabal.project.ghc-8.10 (You can also point it at the right GHC and cabal-install binary if the wrong one is on PATH).

Running ghcide in the benchmark-analysis or any of the source files in it invariably triggers this error.

/CC @mpickering

[pepeiborra]

is ghcide built by the same version of ghc being used to build the codebase?

[merijn]

I'm using 8.6.5 for both. @mpickering was able to reproduce it before too. I suppose I could try what happens if I use 8.10 for both, but since the problem seems to be in the linking of libc I'm not sure whether it'd really affect anything.

[pepeiborra]

How do you build ghcide? If you are downloading a pre-built ghcide binary, it could have been linked to a different libc version.

[pepeiborra]

If you are embedding sqlite and using a statically linked build of ghc, or template haskell for that matter, you are probably running into this bug:

https://gitlab.haskell.org/ghc/ghc/issues/7072

Does ghci work?

You can try to work around it by patching sqlite3.c as in https://github.com/IreneKnapp/direct-sqlite/pull/76/files

[merijn]

I'm building ghcide myself from digital-asset master and from mpickering's fork. Copying ghcide's flags and running ghci manually works fine.

[mpickering]

Have you tried dynamically linking ghcide?

[merijn]

Not yet, is it as simple as dynamic: True in cabal.project or do I need to do something more involved?

[mpickering]

You can add executable-dynamic: True to the cabal.project or pass --enable-execute-dynamic on the command line.

[merijn]

Ok, executable-dynamic: True seems fo fix this issue, so this appears to be the same as the ghc issue @pepeiborra linked, I'm not sure if this can be/should be fixed in GHC, ghcide or it's just a matter of "always link ghcide dynamically", though.

[pepeiborra]

I suspect the advice should indeed be "always link ghcide dynamically", just like ghc itself is built in most platforms.

[jneira]

Ok, maybe we should add the always link ghcide dynamically if ghc is to troubleshooting cause there are several issues here in hls about.