Consider provide dynamically linked precompiled binaries for macos and linux

[jneira]

• As we are suggesting using it to workaround several issues: th problems in macos, compatibility across different linux versions, etc
• Instead ask users to build hls from source in the target machine or enabling dynamic linking we can offer a direct link to the binary
• We will continue using the static linked ones as default, for vscode extension dlownloads, ghcup, etc
  • We can consider distribute them auto later adding them as another alternative (with an option in the vscode extension, adding it in ghcup if it is compatible with the ghc used there //cc @hasufell)
• Documenting the pros and contras (it would need a special ghc version with the bootstrap libraries dynamically linked???)
• It seems they would not be needed in Windows and they would produce more problems than solutions, afaik

cc @pepeiborra

[hasufell]

What problems would a dynamic binary solve on linux?

On mac, you can't statically link anyway, so I don't understand what would change there.

[jneira]

What problems would a dynamic binary solve on linux?

• Document why hls binaries are statically linked (and track ghc changes to allow loading dynamic libs within a static executable) #2000 (comment)
• Please mention haskell-language-server-bin as an alternative (or maybe primary) method of installation on Arch Linux #1634 (about arch)
• Adding a plugin with TH code causes segfault on linux #936 (comment)

and several others (https://github.com/haskell/haskell-language-server/issues?q=is%3Aissue+dynamic+linking+is%3Aclosed)

I think the key is: #1160 (comment)

[jneira]

From my deep ignorance of the linux world, would not be possible to make a hls binary portable across several linux versions linking it dynamically and building it in the more compatible linux version (the lowest one?)

[pepeiborra]

The motivation is best described in #2000 (comment)

Distributing dynamically linked binaries is complicated because you also need to distribute the Haskell package shared objects and any C dependencies. Moreover, you need to manipulate rpaths or use an LD_LIBRARY_PATH wrapper.

[jneira]

Oh, that does not sound good, thanks for noting it 🤔
As you commented elsewhere we would need someone with the required expertise to setup and maintain those distributions.

(As alternative not exclusive i've proposed add the possibility to build hls from source using ghcup: https://gitlab.haskell.org/haskell/ghcup-hs/-/issues/201)

[jneira]

Ok so this is not a good idea given our actual context and there is an alternative, building from source, which could be make easier though ghcup.
Sorry for the noise and thanks for share your thoughts and knowledge