search

haskell / haskell-language-server

Official haskell ide support via language server (LSP). Successor of ghcide & haskell-ide-engine.
Apache License 2.0
2.71k stars 368 forks source link

Support for macOS Big Sur (11.x) and aarch64/M1/Silicon arch #2008

Closed jneira closed 2 years ago

jneira commented 3 years ago

Actual ways to get a working hls executable:

Issue to track the support of hls for this new macOS version

We use github environments to build the binaries and we depend on its supported arch/os versions. Actually we are building macos binaries with this env: https://github.com/actions/virtual-environments/blob/main/images/macos/macos-10.15-Readme.md (macos-latest aka macos 10.15) Not an expert in mac envs but it seems M1 need Big Sur, which is macos 11.00. Github envs has an env for 11.0 but i guess it will be incompatible with older version of macos, so we would have to maintain two macos version in the test and build ci workflows (which has already a big load). In any case it worths to have an issue in the project to track progress in the support of the new version. Anyways does the official ghc version works for big sur? the download page talks about macOS X: https://www.haskell.org/ghc/distribution_packages.html#macosx It seems it works with some caveats: https://www.reddit.com/r/haskell/comments/k9r2cy/workaround_for_haskell_woes_on_macos_11_big_sur/ so maybe the hls version buils for maOS 10.15 would work for 11.x?

UPDATE from #1896

What do we need in order to create and distribute Apple M1 binaries?

//cc @Jaxan

konn commented 3 years ago

FYI, HLS installs and works properly with macOS Big Sur 11.4 on my Intel Mac as long as I don't use -framework features (and I haven't encountered the situation where -framework needed so far). So it seems that the reported behaviour is related to M1-things - but I don't have an access to M1 Mac, I'm NOT 100% confident about it, though. So it might be good to have prebuilt binary for M1 Mac, but it seems GHA doesn't provide M1 Mac environment for the time being.

jneira commented 3 years ago

So it seems that the reported behaviour is related to M1-things - but I don't have an access to M1 Mac, I'm NOT 100% confident about it, though.

So it can be not only os version dependent but also on arch, how quaint! 😝

But afaik there is only one ghc version for Mac and I guess it is not built on a M1 machine (??)

Jaxan commented 3 years ago

Thanks for looking into this. Just to give a bit of context, this is what I did: I installed ghcup via the command on its website, and this successfully installed GHC 8.10.5 and cabal 3.4.0.0. Both tools work fine, but ghcup could not install HLS. (This is the original issue reported at the Haskell gitlab.)

I also tried to do it via visual studio code with the Haskell extension. This downloads its own HLS binary, but it also fails. This is the error I get:

haskell-language-server version: 1.2.0.0 (GHC: 8.10.5) (PATH: /Users/jm1/Library/Application Support/Code/User/globalStorage/haskell.haskell/haskell-language-server-1.2.0-darwin-8.10.5) (GIT hash: 8cfe8b2dbdef965ed735a66de38af425809ae48d)
Starting (haskell-language-server)LSP server...
  with arguments: GhcideArguments {argsCommand = LSP, argsCwd = Nothing, argsShakeProfiling = Nothing, argsTesting = False, argsExamplePlugin = False, argsDebugOn = False, argsLogFile = Nothing, argsThreads = 0, argsProjectGhcVersion = False}
  with plugins: [PluginId "pragmas",PluginId "floskell",PluginId "fourmolu",PluginId "tactics",PluginId "ormolu",PluginId "stylish-haskell",PluginId "retrie",PluginId "brittany",PluginId "class",PluginId "haddockComments",PluginId "eval",PluginId "importLens",PluginId "refineImports",PluginId "moduleName",PluginId "hlint",PluginId "splice",PluginId "ghcide-hover-and-symbols",PluginId "ghcide-code-actions-imports-exports",PluginId "ghcide-code-actions-type-signatures",PluginId "ghcide-code-actions-bindings",PluginId "ghcide-code-actions-fill-holes",PluginId "ghcide-completions",PluginId "ghcide-type-lenses",PluginId "ghcide-core"]
  in directory: /Users/jm1/Documents/git/monoid-learner
 Starting LSP server...
If you are seeing this in a terminal, you probably should have run WITHOUT the --lsp option!
Started LSP server in 0.03s
setInitialDynFlags cradle: Cradle {cradleRootDir = "/Users/jm1/Documents/git/monoid-learner", cradleOptsProg = CradleAction: Cabal}
2021-07-14 14:37:03.974807 [ThreadId 5] INFO hls:   Registering ide configuration: IdeConfiguration {workspaceFolders = fromList [NormalizedUri 6722866727619948082 "file:///Users/jm1/Documents/git/monoid-learner"], clientSettings = hashed Nothing}
2021-07-14 14:37:03.998483 [ThreadId 87] INFO hls:  Consulting the cradle for "app/Main.hs"
2021-07-14 14:37:03.998868 [ThreadId 87] WARNING hls:   No [cradle](https://github.com/mpickering/hie-bios#hie-bios) found for app/Main.hs.
 Proceeding with [implicit cradle](https://hackage.haskell.org/package/implicit-hie).
You should ignore this message, unless you see a 'Multi Cradle: No prefixes matched' error.
Output from setting up the cradle Cradle {cradleRootDir = "/Users/jm1/Documents/git/monoid-learner", cradleOptsProg = CradleAction: Cabal}
> Build profile: -w ghc-8.10.5 -O1
> In order, the following will be built (use -v for more details):
>  - monoid-learner-0.1.0.0 (lib) (first run)
>  - monoid-learner-0.1.0.0 (exe:monoid-learner) (first run)
> Preprocessing library for monoid-learner-0.1.0.0..
> Building library for monoid-learner-0.1.0.0..
> [1 of 2] Compiling KnuthBendix      ( src/KnuthBendix.hs, /Users/jm1/.cache/hie-bios/dist-monoid-learner-153055e40f845441575b002aa26d68b1/build/aarch64-osx/ghc-8.10.5/monoid-learner-0.1.0.0/build/KnuthBendix.o, /Users/jm1/.cache/hie-bios/dist-monoid-learner-153055e40f845441575b002aa26d68b1/build/aarch64-osx/ghc-8.10.5/monoid-learner-0.1.0.0/build/KnuthBendix.dyn_o )
> 
> /var/folders/z1/_xr4v24s5x79ngycy10hskgw0000gq/T/ghc91660_0/ghc_6.s:2:45: error:
>      error: unexpected token at start of statement
>             .p2align        3                               ; -- Begin function s2Gu_info$def
>                                                               ^
>   |
> 2 |         .p2align        3                               ; -- Begin function s2Gu_info$def
>   |                                             ^
>
... MANY SIMILAR LINES SKIPPED ... 
>
> /var/folders/z1/_xr4v24s5x79ngycy10hskgw0000gq/T/ghc91660_0/ghc_6.s:3081:42: error:
>      error: unexpected token at start of statement
>             .quad   3                               ; 0x3
>                                                       ^
>      |
> 3081 |         .quad   3                               ; 0x3
>      |                                          ^
> 
> <no location info>: error:
>     Error running clang! you need clang installed to use the LLVM backend
>     (or GHC tried to execute clang incorrectly)
> `clang' failed in phase `Clang (Assembler)'. (Exit code: 1)
> cabal: Failed to build monoid-learner-0.1.0.0 (which is required by
> exe:monoid-learner from monoid-learner-0.1.0.0).
>

Since it's complaining about some sort of assembly language, I assume it has to do with the M1 chip.

If there is something I can do to debug this issue, please let me know.

demming commented 3 years ago

For cross-reference cf. https://github.com/Homebrew/brew/issues/10152 and the pull request https://github.com/Homebrew/homebrew-core/pull/65997 referenced therein. Homebrew now provides both ghc and haskell-language-server on Apple's ARMv8.4-A arch (aarch64). GHC now provides support for the M1 chipset, see https://www.haskell.org/ghc/blog/20210309-apple-m1-story.html and the links to the GitLab issues therein. Also see https://gitlab.haskell.org/ghc/ghc/-/issues/19512 and https://github.com/ThatGuySam/doesitarm/issues/73. Essentially, as of present, it's GHC 8.10.5's LLVM backend via the Rosetta 2 ISA translator, cf. Homebrew's GHC "formula". Besides, a fix to https://gitlab.haskell.org/ghc/ghc/issues/19410 has been back-ported to 8.10.5.

@jneira: As for the issue you mention in your second bullet point, you might want to look into the HLS "formula" and specifically its Ruby code. As for the GitHub Actions environment, I believe it may yet be reasonable to also build in https://github.com/actions/virtual-environments/blob/main/images/macos/macos-11-Readme.md for the most recent macOS version, provided the resource constraints would still be met. Besides, M1 Macs can't run macOS prior to 11 (Big Sur), and the next release (Monterey) is already available in a public beta preview release and expected this fall.

In addition, there are Homebrew "formulas" for Cabal and Stack. There is however unfortunately no Stackage LTS snapshot as of today that would support GHC 8.10.5 -- I've just opened an issue https://github.com/commercialhaskell/stackage/issues/6115 concerning this caveat

Everything else mentioned above just works on my M1 Macs running the most recent macOS Big Sur version 11.4.

demming commented 3 years ago

@Jaxan: Did you try the Homebrew HLS version? If it doesn't work either, the root cause might be different. Which Clang version do you have on that machine? In particular, your log states 

Error running clang! you need clang installed to use the LLVM backend
(or GHC tried to execute clang incorrectly)
Jaxan commented 3 years ago

Which Clang version do you have on that machine?

My system is relatively new and I did very little custom configuration. I installed Xcode and the command line tools (via the gui of Xcode). So it should be the "normal" clang people will have when they start developing on M1 Macs:

➜  ~ which clang
/usr/bin/clang
➜  ~ clang --version
Apple clang version 12.0.5 (clang-1205.0.22.11)
Target: arm64-apple-darwin20.5.0
Thread model: posix
InstalledDir: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin

Did you try the Homebrew HLS version?

No I haven't tried it before. Let me try ... (some time later) ... Hurray it works 🥳. Visual studio code automatically finds the brew version and it reports some warnings in the IDE. So it seems to be a problem of installing the right version, not a problem with the tools themselves.

Thanks for pointing out this way of installing HLS.

jneira commented 3 years ago

This one and #1896 are essentially duplicates afaiu I am gonna copy the nice summary and checklist done by @pepeiborra from the other one before close it

jneira commented 3 years ago

From a @pepeiborra comment in #1896:

GHC 8.10.5 is out including native binaries for the Apple M1 hardware: https://www.haskell.org/ghc/blog/20210605-ghc-8.10.5-released.html

What do we need in order to create and distribute Apple M1 binaries?

I've set the checklist in the issue description. So afaiu we are blocked upstream on https://github.com/actions/virtual-environments/issues/2187

hasufell commented 3 years ago

What do we need in order to create and distribute Apple M1 binaries?

Use gitlab.haskell.org CI infrastructure, which supports everything GHC supports (including M1, FreeBSD, ...).

jneira commented 3 years ago

Wow that would be a big change in our ci setup and we considered it to get more performance: https://github.com/haskell/haskell-language-server/issues/2039#issuecomment-887794881

jneira commented 3 years ago

Opened an issue in the vscode extension to add the automatic download of artifacts for apple aarch64: https://github.com/haskell/vscode-haskell/issues/458

hasufell commented 3 years ago

Fixed here: https://github.com/haskell/haskell-language-server/pull/2200

https://downloads.haskell.org/~ghcup/unofficial-bindists/haskell-language-server/1.4.0/haskell-language-server-macOS-aarch64-1.4.0.tar.gz

jneira commented 3 years ago

I've added to main description the actual ways to get a working executable in aarch64:

jneira commented 2 years ago

We are building hls on macos + aarch in gitlab and the binaries used in ghcup are also included in our release artifacts.

jneira commented 2 years ago

Issue tracking the automatic download of macos aarch binaries in vsocde here: https://github.com/haskell/vscode-haskell/issues/458

jneira commented 2 years ago

We are building hls on macos + aarch in gitlab and the binaries used in ghcup are also included in our release artifacts.

I think we can close this as the missing piece in the extension is tracked in the issue linked above

sliminality commented 2 years ago

Apologies if this is the wrong place to comment, but the release artifacts for haskell-language-server-macOS-aarch64-1.6.1.0.tar.xz only contains a binary compiled against 8.10.7 (and not 9.2.1 or any other version). Is there some fundamental limitation preventing HLS from working with GHC 9.2.1 on M1 architecture?

hasufell commented 2 years ago

Apologies if this is the wrong place to comment, but the release artifacts for haskell-language-server-macOS-aarch64-1.6.1.0.tar.xz only contains a binary compiled against 8.10.7 (and not 9.2.1 or any other version). Is there some fundamental limitation preventing HLS from working with GHC 9.2.1 on M1 architecture?

Yes, 9.2.1 is busted on M1 https://gitlab.haskell.org/ghc/ghc/-/issues/20592