Dynlinked binaries use wrong ghc-paths inside TH

[pepeiborra]

Your environment

Which OS do you use:
MacOS

Which LSP client (editor/plugin) do you use:
VSCode

Describe your project (alternative: link to the project):
HLS 1.7 distro binaries gives an unexpected diagnostic when type checking TH code that uses GHC.Paths.libdir

Steps to reproduce

Load the ghcide codebase and open ghcide/session-loader/Development/IDE/Session/VersionCheck.hs. The referenced function makeGhcVersionChecker comes from the ghc-check package and is throwing at:

  libdir <- GHC.Paths.getLibdir
  libdirExists <- doesDirectoryExist libdir
  unless libdirExists
    $ error
    $ "I could not find a GHC installation at " <> libdir
      <> ". Please do a clean rebuild and/or reinstall GHC."
  ...

Expected behaviour

No diagnostics are shown, the code compiles

Actual behaviour

• Exception when trying to run compile-time code:
    I could not find a GHC installation at /Users/builder/builds/oBRYs8oB/0/haskell/haskell-language-server/toolchain/.ghcup/ghc/8.10.7/lib/ghc-8.10.7. Please do a clean rebuild and/or reinstall GHC.
CallStack (from HasCallStack):
  error, called at src/GHC/Check.hs:188:7 in ghc-chck-0.5.0.6-2fb35c95:GHC.Check
  Code: makeGhcVersionChecker
          (fromMaybe GHC.Paths.libdir <$> lookupEnv "NIX_GHC_LIBDIR")
• In the Template Haskell splice
    $$(makeGhcVersionChecker
         (fromMaybe GHC.Paths.libdir <$> lookupEnv "NIX_GHC_LIBDIR"))
  In the expression:
    $$(makeGhcVersionChecker
         (fromMaybe GHC.Paths.libdir <$> lookupEnv "NIX_GHC_LIBDIR"))
  In an equation for ‘ghcVersionChecker’:
      ghcVersionChecker
        = $$(makeGhcVersionChecker
               (fromMaybe GHC.Paths.libdir <$> lookupEnv "NIX_GHC_LIBDIR"))

Include debug information

• The problem does not arise when using locally built HLS 1.7 binaries.
• My ghc lives in /home/pepeiborra/.ghcup/ghc/8.10.7. The diagnostic is looking for it in /Users/builder/builds/oBRYs8oB/0/haskell/haskell-language-server/toolchain/.ghcup/ghc/8.10.7/lib/ghc-8.10.7 which looks like a CI builder location.

[michaelpj]

I think this might actually be a cabal bug. I've observed something like this before. I think the ghc-paths package can get cached with an old/nonexistent path for GHC, and then not get rebuilt properly. What happens if you purge ghc-paths from the store?

[pepeiborra]

You are probably right, I tried the prebuilt 1.7.0 HLS binaries for 9.0.2 and 9.2.2 and couldn't reproduce. So far it repros with 8.10.7 only.

Purging ghc-paths from the store seems to have left Cabal in an inconsistent state:

internal error in InstallPlan.completed: not in configured state: Installed ghc-xctprnt-0.6.4-dd8b2473
CallStack (from HasCallStack):
  error, called at src/Distribution/Client/InstallPlan.hs:259:25 in main:Distribution.Client.InstallPlan
  internalError, called at src/Distribution/Client/InstallPlan.hs:655:26 in main:Distribution.Client.InstallPlan

UPDATE: Fixed the inconsistent state by purging all the reverse dependencies and letting Cabal rebuild them: the issue came back.

[michaelpj]

Yeah, sorry, I should have mentioned that you might need to do that.

I think I fixed something like this for myself somehow, but I can't remember exactly how, sorry :/

[michaelpj]

Tentatively closing, nobody has complained about this recently