(the binaries hie and hie-wrapper were copied), opening in the new stub project nvim src/Main.hs with resolver: lts-14.19 or 14.18,
using hie-wrapper or stack exec ghcide for the invocation of the language server,
results in
Error:hie: "panic! (the 'impossible' happened)
(GHC version 8.4.4 for x86_64-unknown-linux):
Dynamic linker not initialised
Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
even though the project resolver is for GHC 8.6.5. The wrong version of hie is run, but the process hie-8.4.4 has not been started.
was not enough, but then terminating the hie processes,
$ killall -9 hie-wrapper hie hie-8.6.5 ghcide
solved the issue.
1386 is somewhat related. I'll investigate the issue further a bit later.
I believe that hie and hie-wrapper should not depend on the order of installation. For instance, I have older hie-8.* binaries (2019-11-01) for all but hie-8.4.4 and hie-8.6.5 (2019-12-28), which I'd expect not to have to rebuild unnecessarily. It is clear, that the overhead from running stack ./install ... for compiled binaries is minimal, but to maintain the order would involve rebuilding the entire hie project.
For a stub project,
which goes now with
resolver: lts-14.19
(has no effect if reduced tolts-14.18
) instack.yaml
,having previously installed
hie
via(the binaries
hie
andhie-wrapper
were copied), opening in the new stub projectnvim src/Main.hs
withresolver: lts-14.19
or14.18
,using
hie-wrapper
orstack exec ghcide
for the invocation of the language server,results in
even though the project resolver is for GHC 8.6.5. The wrong version of
hie
is run, but the processhie-8.4.4
has not been started.For background, see https://gitlab.haskell.org/ghc/ghc/issues/9868, resolved in GHC 8.6.1.
Simply reinstalling
hie-8.6.5
,was not enough, but then terminating the
hie
processes,solved the issue.
1386 is somewhat related. I'll investigate the issue further a bit later.
I believe that
hie
andhie-wrapper
should not depend on the order of installation. For instance, I have olderhie-8.*
binaries (2019-11-01) for all buthie-8.4.4
andhie-8.6.5
(2019-12-28), which I'd expect not to have to rebuild unnecessarily. It is clear, that the overhead from runningstack ./install ...
for compiled binaries is minimal, but to maintain the order would involve rebuilding the entirehie
project.