Closed konn closed 8 months ago
This is unfortunate. Multiple versions of certain configurations of GHC 9.0.2 were released, due to issues with missing profiling libraries. See https://downloads.haskell.org/ghc/9.0.2/ which has both ghc-9.0.2a-x86_64-fedora27-linux.tar.lz with thr profiling libraries and ghc-9.0.2-x86_64-fedora27-linux.tar.lz without profiling libraries.
However, as these are distinct builds, they are incompatible with each other. Furthermore, GHCup doesn't have a concept of revisions, so the bindists distributed and built in CI were built against 9.0.2a, while stack is probably using the original GHC 9.0.2.
See also https://gitlab.haskell.org/haskell/ghcup-hs/-/issues/351 and https://gitlab.haskell.org/ghc/ghc/-/issues/21423#note_423952
As a workaround, we could make a HLS release linked against the original 9.0.2 build and modify the install script to automatically detect the correct variant to use.
Ah, I was aware of the missing profiling library in GHC 9.0.2, but am not aware the release of the corrected version. I'm curious whether stack will re-install GHC 9.0.2-a if I nuke the current GHC 9.0.2 environment (without profiling). If that is the case, I can just reinstall ghc 9.0.2 for stack as a workaround.
I think you can also configure stack to download the 9.0.2a version manually if it doesn't automatically do so: https://docs.haskellstack.org/en/stable/yaml_configuration/#setup-info-locations
Note that if you do this, please delete the cached/installed libraries for GHC 9.0.2 in .stack-work
or you will get segfaults when trying to run anything.
think you can also configure stack to download the 9.0.2a version manually if it doesn't automatically do so: https://docs.haskellstack.org/en/stable/yaml_configuration/#setup-info-locations
Aha, that makes sense! It seems that stack won't use 9.0.2a in my environment, so I will try that feature.
I confirmed that specifying setup-info
properly in ~/.stack/config.yaml
(and compiling everything from the ground up) works with the prebuilt dynamic binary!
I would remain this issue open (as no permanent workaround is implemented). Perhaps it might be still good to document this situation
I've opened up https://github.com/commercialhaskell/stackage-content/pull/102 to get stack to pull down the 9.0.2a release. Which should help with this issue.
I confirmed that specifying
setup-info
properly in~/.stack/config.yaml
(and compiling everything from the ground up) works with the prebuilt dynamic binary!I would remain this issue open (as no permanent workaround is implemented). Perhaps it might be still good to document this situation
It's documented here https://github.com/haskell/vscode-haskell#ghc-abis-dont-match at least... but yes, should also be documented in HLS
This was a problem with 9.0.2, which isn't supported any more
Your environment
Which OS do you use: Ubuntu 20.04.2 LTS
Which LSP client (editor/plugin) do you use: VSCode + vscode-haskell
Describe your project (alternative: link to the project): plain project created by
stack new
+ extra dependency for boot library (e.g. transformers)Stack version: Version 2.7.5, Git revision ba147e6f59b2da75b1beb98b1888cce97f7032b1 x86_64 hpack-0.34.4
Steps to reproduce
Enable
vscode-haskell
Prelease v2.1.3 and make sure it downloads the latest dynamic binary.cabal-install
+ GHC 9.0.2 installed via GHCup and specify the HLS path to it.stack new dummy-project --resolver lts-19.5
.Add
transformers
to thedependencies
section ofpackage.yaml
:3.open
src/Main.hs
Expected behaviour
HLS should just work.
Actual behaviour
Line 1 is highlighted with the following linking error:
The error vanishes when one compiles HLS manually with stack.
Include debug information
Here is the debug output of
Haskell
section ofOutput
tab in VSCode (with verbose tracing configuration):