HLS is broken with some TH code: "Error dynamically loading libm.so.6"

[sonowz]

Your environment

• VSCode
• NixOS 20.09, with either remote-SSH or remote-WSL
• haskell-language-server version: 1.0.0.0
• stack : 2.3.3

The error

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

The cause

haskell-language-server/ghcide/session-loader/Development/IDE/Session.hs

Lines 345 to 349 in b9c6e6c

	res <- loadDLL hscEnv "libm.so.6"
	case res of
	Nothing -> pure ()
	Just err -> hPutStrLn stderr $
	"Error dynamically loading libm.so.6:\n" <> err

Related PR: haskell/ghcide#723

The cause is straightforward: by default NixOS does not have libm.so.6 nor glibc in its system environment. Thus HLS literally can't load libm.so.6.

The workaround

Setting LD_LIBRARY_PATH to the path which libm.so.6 lives works and the error is gone. XD

with import <nixpkgs> {};
stdenv.mkDerivation {
  name = "glibc-patch";
  buildInputs = [ glibc ];
  LD_LIBRARY_PATH = "${glibc}/lib/";
}

Long description

For NixOS, it seems like the error is raised every time I use HLS.
Generally, HLS works as normal, and the error doesn't affect anything. Just error message above (Error dynamically loading libm.so.6).
However, if the source code uses some TemplateHaskell, almost every HLS feature is broken and produces error below. No code highlighting, no type hints.

I think HLS is broken only when system calls in libm.so.6 really gets called.

[jneira]

@sonowz wow, this is a almost perfect bug report, many thanks 😄

Not sure what could be a definitive solution, pinging @pepeiborra just in case.

[pepeiborra]

The best solution is probably to build HLS with Nix, and not reuse the pre-built binaries

[sonowz]

I came up with something like this:

res <- loadDLL hscEnv "libm.so.6" 
case res of 
  Nothing -> pure () 
  Just err -> downloadLibM >> loadDLL hscEnv "libm.so.6"

Is this possible? I have no expertise in these OS-level thingy..

[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!