Server cannot find hls-qualify-improted-names-plugin .so file (missing from ghcup install?)

[tslawler]

Your environment

Which OS do you use?
Ubuntu 22.04
Which version of GHC do you use and how did you install it?
9.4.8 from ghcup
How is your project built (alternative: link to the project)?
cabal

Which LSP client (editor/plugin) do you use?
VS Code Haskell extension
Which version of HLS do you use and how did you install it?
v2.7.0.0 via ghcup
Have you configured HLS in any way (especially: a hie.yaml file)?
No

What's wrong?

Trying to run HLS gives an error that it cannot find a shared library libHShaskell-language-server-2.7.0.0-l-hls-qualify-imported-names-plugin-(...)-ghc9.4.8.so. And indeed if I look in ~/.ghcup/hls/2.7.0.0/lib/haskell-language-server-2.7.0.0/lib/9.4.8/, there is no such file.

Just to be sure, I checked the 9.8.2 directory and it's also not in there.

Debug information

$ haskell-language-server-wrapper --debug
No 'hie.yaml' found. Try to discover the project type!
Run entered for haskell-language-server-wrapper(haskell-language-server-wrapper) Version 2.7.0.0 x86_64 ghc-9.2.8
Current directory: /home/thomas/Projects/hlox
Operating system: linux
Arguments: ["--debug"]
Cradle directory: /home/thomas/Projects/hlox
Cradle type: Cabal

Tool versions found on the $PATH
cabal: 3.10.2.1
stack: 2.13.1
ghc: 9.4.8

Consulting the cradle to get project GHC version...
2024-03-16T19:04:50.992505Z | Debug | cabal exec -v0 -- ghc --print-libdir
2024-03-16T19:04:51.147451Z | Debug | cabal exec -v0 -- ghc -package-env=- -ignore-dot-ghci -e Control.Monad.join (Control.Monad.fmap System.IO.putStr System.Environment.getExecutablePath)
2024-03-16T19:04:51.224244Z | Debug | cabal --builddir=/home/thomas/.cache/hie-bios/dist-hlox-1a935d12146f65740c93580ab0e3a370 v2-exec --with-compiler /home/thomas/.cache/hie-bios/wrapper-b54f81dea4c0e6d1626911c526bc4e36 --with-hc-pkg /home/thomas/.cache/hie-bios/ghc-pkg-f991dad7f140da4685186d716b70b438 ghc -v0 -- --numeric-version
Environment Variables
HIE_BIOS_GHC: /home/thomas/.ghcup/ghc/9.4.8/lib/ghc-9.4.8/bin/ghc-9.4.8
HIE_BIOS_GHC_ARGS: -B/home/thomas/.ghcup/ghc/9.4.8/lib/ghc-9.4.8/lib
Project GHC version: 9.4.8
haskell-language-server exe candidates: ["haskell-language-server-9.4.8","haskell-language-server"]
Launching haskell-language-server exe at:/home/thomas/.ghcup/bin/haskell-language-server-9.4.8
2024-03-16T19:04:51.303610Z | Debug | cabal exec -v0 -- ghc --print-libdir
2024-03-16T19:04:51.457805Z | Debug | cabal exec -v0 -- ghc -package-env=- -ignore-dot-ghci -e Control.Monad.join (Control.Monad.fmap System.IO.putStr System.Environment.getExecutablePath)
2024-03-16T19:04:51.614621Z | Debug | cabal --builddir=/home/thomas/.cache/hie-bios/dist-hlox-1a935d12146f65740c93580ab0e3a370 v2-exec --with-compiler /home/thomas/.cache/hie-bios/wrapper-b54f81dea4c0e6d1626911c526bc4e36 --with-hc-pkg /home/thomas/.cache/hie-bios/ghc-pkg-f991dad7f140da4685186d716b70b438 ghc -v0 -- -v0 -package-env=- -ignore-dot-ghci -e Control.Monad.join (Control.Monad.fmap System.IO.putStr System.Environment.getExecutablePath)
Environment Variables
HIE_BIOS_GHC: /home/thomas/.ghcup/ghc/9.4.8/lib/ghc-9.4.8/bin/ghc-9.4.8
HIE_BIOS_GHC_ARGS: -B/home/thomas/.ghcup/ghc/9.4.8/lib/ghc-9.4.8/lib
2024-03-16T19:04:51.693325Z | Debug | cabal exec -v0 -- ghc --print-libdir
2024-03-16T19:04:51.847618Z | Debug | cabal exec -v0 -- ghc -package-env=- -ignore-dot-ghci -e Control.Monad.join (Control.Monad.fmap System.IO.putStr System.Environment.getExecutablePath)
2024-03-16T19:04:51.914209Z | Debug | cabal --builddir=/home/thomas/.cache/hie-bios/dist-hlox-1a935d12146f65740c93580ab0e3a370 v2-exec --with-compiler /home/thomas/.cache/hie-bios/wrapper-b54f81dea4c0e6d1626911c526bc4e36 --with-hc-pkg /home/thomas/.cache/hie-bios/ghc-pkg-f991dad7f140da4685186d716b70b438 ghc -v0 -- --print-libdir
Environment Variables
HIE_BIOS_GHC: /home/thomas/.ghcup/ghc/9.4.8/lib/ghc-9.4.8/bin/ghc-9.4.8
HIE_BIOS_GHC_ARGS: -B/home/thomas/.ghcup/ghc/9.4.8/lib/ghc-9.4.8/lib
/home/thomas/.ghcup/hls/2.7.0.0/lib/haskell-language-server-2.7.0.0/bin//haskell-language-server-9.4.8: error while loading shared libraries: libHShaskell-language-server-2.7.0.0-l-hls-qualify-imported-names-plugin-6c99426d851435d186c607a3a593b9558e1a11f29351f1465cf1211047315fc0-ghc9.4.8.so: cannot open shared object file: No such file or directory

[fendor]

Hi! Thank you for your bug report!

Locally, I do have that path and the tar ball https://downloads.haskell.org/~ghcup/unofficial-bindists/haskell-language-server/2.7.0.0/haskell-language-server-2.7.0.0-x86_64-linux-ubuntu22.04.tar.xz also contains this shared library.

Perhaps installation was interrupted for some reason? Have you tried reinstalling this HLS version via ghcup rm hls 2.7.0.0 and then running ghcup install hls 2.7.0.0?

[agreyyy]

I am getting the same issue on neovim too, when using the 2.7.0 version of HLS downloaded by Mason. here are the logs if you are interested, reinstalling did not help.

[fendor]

Are you on the same platform?

[agreyyy]

Are you on the same platform?

Yeah sorry I shouldve specified all those details earlier:
Which OS do you use?
Linux Mint 21.3
Which version of GHC do you use and how did you install it?
(9.2.7 and 9.6.4) from ghcup
How is your project built (alternative: link to the project)?
cabal
Which LSP client (editor/plugin) do you use?
Haskell-tools.nvim (neovim)
Which version of HLS do you use and how did you install it?
v2.7.0.0 via Mason nvim
Have you configured HLS in any way (especially: a hie.yaml file)?
No

[fendor]

Very unsettling! cc @hasufell, perhaps you have an idea what's up?

[hasufell]

I can't reproduce. I tried in a linuxmintd/mint21.3-amd64 docker container with default and vanilla channel. Everything works. The file is there.

[agreyyy]

idk what else to tell you, I did a ghcup nuke, then installed ghc, stack, cabal, ghcup via the curl script in the download haskell page on the official website, and set up a minimal reproduction of haskell-tools.nvim in neovim with their minimal.lua file and ran neovim. Same error, also same error with the VsCode Haskell extension,tried with both the Mason install of HLS and local install of HLS (both 2.7.0.0, compatible with 9.4.8 ghc). LSP logs are the same too.

[hasufell]

Is the file there? If so, what does ldd show?

[agreyyy]

no file does not exist, /home/andrey/.local/share/nvim/mason/packages/haskell-language-server/lib/haskell-language-server-2.7.0.0/bin//haskell-language-server-9.4.8 does exist, its trying to find some shared object (so) file and I have no idea what path its trying to find that file at. Some .so file called libHShaskell-language-server-2.7.0.0-l-hls-qualify-imported-names-plugin-6c99426d851435d186c607a3a593b9558e1a11f29351f1465cf1211047315fc0-ghc9.4.8.so

[hasufell]

Search for the file in the install directory

[tslawler]

Sorry for the long-delayed response.

I tried ghcup rm hls 2.7.0.0 + ghcup install hls 2.7.0.0 and got nowhere. The shared-object file still isn't there:

$ ls .ghcup/hls/2.7.0.0/lib/haskell-language-server-2.7.0.0/lib/9.4.8/ | grep qual
libHStype-equality-1-4c4c74459b9beac3450b8c89d5e44e349246b3380947be50f84b6d23d84c2245-ghc9.4.8.so

Here's the ghcup log from my latest attempt:
ghcup.log

I tried downloading the .tar.xz file from the link @fendor mentioned myself and extracting it, and when I do so I get a bunch of error messages like:

Extraction of the entry:
‘haskell-language-server-2.7.0.0/lib/9.6.4/libHShaskell-language-server-2.7.0.0-l-hls-change-type-signature-plugin-9cf5ca140c3238572d33eb14876617115036b9e737c4f0c38453531ec2577f51-ghc9.6.4.so’
failed with the error message:
Could not stat haskell-language-server-2.7.0.0/lib/9.6.4/libHShaskell-language-server-2.7.0.0-l-hls-change-type-signature-plugin-9cf5ca140c3238572d33eb14876617115036b9e737c4f0c38453531ec2577f51-ghc9.6.4.so

which suggests that something's wrong with that archive.

[tslawler]

... are you kidding me, tar?

tar: haskell-language-server-2.7.0.0/lib/9.2.8/libHShaskell-language-server-2.7.0.0-l-hls-qualify-imported-names-plugin-75a9bd06159e62d5f1322a9beb4f918df5856d410f8b296fac964b1e69fd6f7a-ghc9.2.8.so: Cannot open: File name too long

[tslawler]

Okay, on further investiagation, the problem isn't tar, it's ecryptfs. File names longer than 143 characters are not supported on ecryptfs (see e.g. https://bugs.launchpad.net/ecryptfs/+bug/344878). The hls plugins are just barely long enough to trigger that issue (the qualify-imported-names one is 150 characters long, and not the only one with that issue).

It's really annoying that ghcup doesn't report any kind of error when it can't unpack a file; it would have saved a bunch of time if it had pointed out that 'file name too long' error message when it was trying to install hls.

[hasufell]

It's really annoying that ghcup doesn't report any kind of error when it can't unpack a file

We use libarchive to unpack. It's possible it swallows the error.

What is the easiest way to reproduce this?

[tslawler]

Probably the easiest way is something like:

1. sudo apt install ecryptfs-utils libecryptfs1
2. Add a new user, log in as that user, and run ecryptfs-setup-private -a
3. Do the standard ghcup install process for that user
4. Use ghcup to install hls
5. Profit?

Honestly given that ecryptfs hasn't been actively supported in over five years, it's probably best to just let it die; I've managed to disable it by following the instructions here: https://askubuntu.com/a/862599 and that lets ghcup successfully unpack the .so files.

[tslawler]

(That said, do these filenames really need to be this long? "libHShaskell-language-server-2.7.0.0-l-hls-qualify-imported-names-plugin" mentions HLS twice, both expanded and abbreviated, there's a 512-bit hash spelled out as 64 hex digits, and "-ghc9.2.8" or whatever is implied by the directory structure.)

[hasufell]

I'm not gonna support ecryptfs. I'm only interested in why unpacking doesn't error properly.

[tslawler]

Another thing that may assist you is that it seems like docker has a filename limit of 242 characters (rather than 255 on most linuxes), so making a tarball with a 250-character name and trying to get ghcup to unpack it in a docker container may help?

[fendor]

Closed as we can't do much about it here. This is an error with bindists and ecryptfs isn't supported.

[edsko]

Another ecryptfs user here that is bitten by this :(

[hasufell]

I guess we could get rid of the hash in the SO filename. For the purpose of the bindist, it really is irrelevant.

So we either use cabal v1 to build the bindist or summon some patchelf dragons.

[edsko]

It's probably true that ecryptfs users are a very small group (it's only a plan B for me to be using it myself, but plan A involves installing LUKS, which isn't an option right now), so probably not worth spending a lot of time on.

Just for the record, since @fendor mentions "this is an error with bindists", I figured I'd give a compile-from-source a try, but that fails too (but at least with --verbose with a better error message):

$ ghcup --verbose compile hls -v 2.9.0.0 --ghc 9.4.8 
(...)
Configuring library 'hls-qualify-imported-names-plugin' for haskell-language-server-2.9.0.0...
Preprocessing library 'hls-qualify-imported-names-plugin' for haskell-language-server-2.9.0.0...
Building library 'hls-qualify-imported-names-plugin' for haskell-language-server-2.9.0.0...
[1 of 1] Compiling Ide.Plugin.QualifyImportedNames ( plugins/hls-qualify-imported-names-plugin/src/Ide/Plugin/QualifyImportedNames.hs, dist/build/hls-qualify-imported-names-plugin/Ide/Plugin/QualifyImportedNames.o, dist/build/hls-qualify-imported-names-plugin/Ide/Plugin/QualifyImportedNames.dyn_o )
Installing internal library hls-qualify-imported-names-plugin in /home/edsko/.cabal/store/ghc-9.4.8/incoming/new-81344/home/edsko/.cabal/store/ghc-9.4.8/haskell-language-server-2.9.0.0-l-hls-qualify-imported-names-plugin-b6be76afc5e1a917bf9c18cc976b7d8fdefca72bbc9e197dc8b07cc6ec3dbf2c/lib
dist/build/hls-qualify-imported-names-plugin/libHShaskell-language-server-2.9.0.0-l-hls-qualify-imported-names-plugin-b6be76afc5e1a917bf9c18cc976b7d8fdefca72bbc9e197dc8b07cc6ec3dbf2c-ghc9.4.8.so: copyFile: invalid argument (File name too long)
Error: [Cabal-7125]

[edsko]

I worked around the problem by symlinking ~/.ghcup to /opt/ghcup (which does not use ecryptfs). It's not important that the ghcup/ghc installs are encrypted, after all.

[hasufell]

I worked around the problem by symlinking ~/.ghcup to /opt/ghcup (which does not use ecryptfs). It's not important that the ghcup/ghc installs are encrypted, after all.

You can use export GHCUP_INSTALL_BASE_PREFIX=/opt and it will use /opt/.ghcup. No symlinks needed.