hls fails with multiple executables, stack and implicit hie-bios config

[eborden]

The new VSCode static binaries work fantastically. However they seem to fail in the presence of stack and multiple executables within a project.

When running the project for this repo I get the following. This is consistent with other multiple executable repos I've tried.

Failed to parse result of calling stack

* * * * * * * *
The main module to load is ambiguous. Candidates are: 
1. Package `asana' component asana:exe:bug-reproduction with main-is file: /home/eborden/code/asana/bug-reproduction/Main.hs
2. Package `asana' component asana:exe:close-iteration with main-is file: /home/eborden/code/asana/close-iteration/Main.hs
3. Package `asana' component asana:exe:cycle-time with main-is file: /home/eborden/code/asana/cycle-time/Main.hs
4. Package `asana' component asana:exe:debt-evaluation with main-is file: /home/eborden/code/asana/debt-evaluation/Main.hs
5. Package `asana' component asana:exe:planning-poker with main-is file: /home/eborden/code/asana/planning-poker/Main.hs
6. Package `asana' component asana:exe:start-iteration with main-is file: /home/eborden/code/asana/start-iteration/Main.hs
7. Package `asana' component asana:exe:update-task with main-is file: /home/eborden/code/asana/update-task/Main.hs
You can specify which one to pick by: 
 * Specifying targets to stack ghci e.g. stack ghci asana:exe:bug-reproduction
 * Specifying what the main is e.g. stack ghci --main-is asana:exe:bug-reproduction
 * Choosing from the candidate above [1..7]
* * * * * * * *

<stdin>: hGetLine: end of file

[fendor]

Hi! This is currenlty expected behaviour. You need to add a hie.yaml file to the root of your project which maps out how HLS should load your project.
Some information: https://github.com/mpickering/hie-bios/#stack

If you need more information, please ask! We are trying to improve the docs for hie.yaml

[jneira]

Only want to mention that there is a utility to help generating the hie-yaml: gen-hie. You can get it with stack install implicit-hie.
This will be solved when hls/ghcide will use directly implicit-hie as discused in #38

[eborden]

Thanks for the info! A great improvement would be parsing this response and providing info/links about hie.yaml. Right now the parse error is a dead end.

[sjshuck]

Only want to mention that there is a utility to help generating the hie-yaml: gen-hie. You can get it with stack install implicit-hie.
This will be solved when hls/ghcide will use directly implicit-hie as discused in #38

I did this and generated the hie.yaml and now instead of getting the "module is ambiguous" error, I have another error:

[cradle] [E] ghcide compiled by GHC 8.8 failed to load packages: <command line>: cannot satisfy -package parcopy-0.1.1.0
    (use -v for more information). 
Please ensure that ghcide is compiled with the same GHC installation as the project.

I did stack install ghcide and that made no difference.

[Ailrun]

@sjshuck If you build your project once, does that work afterward? I mean, running stack build at your project root.

[sjshuck]

@Ailrun I had previously built the package. Reran stack install anyway; same error.
Some more info, if this helps. The way I interpreted the advice given here was to run this:

stack install implicit-hie
gen-hie >hie.yaml

Also, when I open a source file that's shared between my two executables, the error is different:

[typecheck] [E] Installation error: unable to load package `ghc-prim-0.5.3'

The relevant part of my stack.yaml is here: https://github.com/IBM/parcopy/blob/0b49380499b209321202b90c2b0e8de75a44ed7e/package.yaml#L38

[Ailrun]

Hm... maybe you installed HLS of a different version of GHC from what you are using for the project? In your previous comment, you said you ran stack install ghcide, but actually ghcide is a part of HLS, so the error message should be interpreted as:

Please ensure that haskell-language-server is compiled with the same GHC installation as the project

You can check whether it use the same version by checking that your list of binaries includes haskell-language-server-<GHC-version-you-are-using>.
If it doesn't, then probably that's the root of the problem.
(To be clearer, the version should have the same patch version too, not just the same minor version)

[sjshuck]

Re-downloaded everything just to make sure.

$ stack exec -- ghc --version
The Glorious Glasgow Haskell Compilation System, version 8.8.3
$ curl -L https://github.com/haskell/haskell-language-server/releases/download/0.2.2/haskel
l-language-server-Linux-8.8.3.gz | gunzip >~/.local/bin/haskell-language-server-8.8.3
<downloaded fine, 22MB>
$ chmod +x ~/.local/bin/haskell-language-server-8.8.3
$ haskell-language-server-<tab completion>
haskell-language-server-8.8.3    haskell-language-server-wrapper

Same error.

[sjshuck]

Interesting that it says ghcide compiled by GHC 8.8, without the patch version.

[Ailrun]

It would be better if I can see your full log and the generated hie.yaml.

@bubba, this may be related to binary build process? I'm not sure but for the case.

[sjshuck]

Please find my hie.yaml and hls.log (debug output) here: https://github.com/IBM/parcopy/tree/debug-hls

[lukel97]

@Ailrun I wouldn't rule it out, [typecheck] [E] Installation error: unable to load package ghc-prim-0.5.3'` looks kind of like #221. @sjshuck if you install hls from source do you get the same error?

[sjshuck]

@bubba No, that other error went away, thanks!
Original error persists.

[pe200012]

Same problem here. After enabling TemplateHaskell and then using something like maksLenses ''Foo, hls would give me error message like this:

[typecheck] [E] Installation error: unable to load package ghc-prim-0.5.3

Stack snapshot: lts-16.7
HLS: downloaded from github releases, e44f618

[Vorticity-Flux]

I've got the same issue with template haskell enabled. This issue seem to occur if loading dynamic library fails (this linking happens even for fully static HLS executable). I've got following in the HLS log:

Error dynamically loading libm.so.6:
libm.so.6: cannot open shared object file: No such file or directory

This error comes from #293, that fix probably works fine in other distributions but fails on NixOS as libm is not in it's usual path.

[Vorticity-Flux]

To anyone stuck with the same issue on NixOS: hls version in haskell-updates branch of nixpkgs have hls 0.3.0 that does not have this problem (normal unstable branch still have hls 0.2.2).

[jneira]

Not sure if it is only th related but it would worth to revisit this once we use ghcide version with better support for th: #526

[jneira]

We are using in 0.6.0 a ghcide version with better th support: @eborden @Vorticity-Flux @sjshuck please, could you check if that version fix the error for you?

[eborden]

@jneira I took a stab at running it in my "large" repo. It worked as expected on modules/packages it had previously worked on. When I moved to the previously failing module the extension crashed 5 times and then stopped functioning.

In the logs I'm seeing:

2020-11-17 17:14:27.869103639 [ThreadId 20] - Finishing build session(exception: AsyncCancelled)

I can dump my whole log with a few messages redacted (ones that include source code) if that would be helpful.

[jneira]

@eborden thanks for trying

[eborden]

@jneira not sure if there is anything useful for you in here: https://gist.github.com/eborden/a2648dc9374d7de2029d32303238ccfd

[codygman]

I can confirm I get the libm error using stack --nix:

[INFO] Making new HscEnv[main]
Error dynamically loading libm.so.6:
libm.so.6: cannot open shared object file: No such file or directory

[solomon-b]

Is there a known solution for this with nixos? I'm using HLS 1.0 and am getting the same error as many others here:

Error dynamically loading libm.so.6:
libm.so.6: cannot open shared object file: No such file or directory

[sonowz]

@codygman @ssbothwell
I think libm.so.6 error is not related to this issue; I opened a new issue #1601.
I wrote down how to fix the error there :)

[jneira]

I am gonna close this issue as all compiler crashes seems to have the same root cause:

• We have a general issue about: Improve template haskell support (upstream fix and workaround for compiler crashes) #1431
• And other one with more info about the causes: Document why hls binaries are statically linked (and track ghc changes to allow loading dynamic libs within a static executable) #2000
• We have a generic workaround (build hls from source dynamically linked) documented in the troubleshooting guide: https://haskell-language-server.readthedocs.io/en/latest/troubleshooting.html#static-binaries-and-template-haskell-support
• And a possible fix upstream for ghc described in Document why hls binaries are statically linked (and track ghc changes to allow loading dynamic libs within a static executable) #2000 (comment)

If any of you think the issue should not be included generically feel free to reopen it (with a brief explanation if possible)
Thanks all!