'unknown symbol' error when running hls on the stack codebase

[theobat]

Hi,

The repo where this happens is https://github.com/commercialhaskell/stack/
I slightly modified the package.yaml to use GHC 8.8.3 and LTS-16.9 (but an older one does not change this issue)

I get:

haskell-language-server-8.8.3: 
lookupSymbol failed in relocateSection (relocate external)
/Users/theophile/.stack/snapshots/x86_64-osx/63fd7302eafdb4f0848748d641de7b97f139e859d01e32c9b472b68facb0ed5d/8.8.3/lib/x86_64-osx-ghc-8.8.3/hackage-security-0.6.0.1-EOE2VKs23b41HWmlFHCnG/libHShackage-security-0.6.0.1-EOE2VKs23b41HWmlFHCnG.a: unknown symbol `___dso_handle'

I'm not sure what to do with this or where it comes from, I didn't find any occurence of ___dso_handle on google.
Here's an interesting GHC issue though, I'm trying to see if something can be done at the hackage-security level (or a shared C lib they use)
Also, maybe it's unrelated, but Template Haskell is used in several places in the stack codebase.

[theobat]

Another interesting thread on google about ___dso_handle:
https://mail.haskell.org/pipermail/haskell-cafe/2011-January/088041.html

It definitely seems to be related to template haskell, in particular:

It seems to me that TH (when used with cabal) loads all packages
specified at "Build-Depends" in your cabal file (whether they are needed
or not). ghc --make instead just loads all packages, that are really
needed for THs code generation.

[theobat]

Yet another interesting suggestion in (untested for now) : https://stackoverflow.com/questions/26449154/a-workaround-for-the-template-haskell-c-bug

Seems like this is also an issue on linux (the linking fails, with different errors though)

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