Unable to setup on mac #34

tonyalaribe · 2021-05-10T15:39:26Z

I have this error while trying to setup tree-sitter haskell on a mac:

Do you have any ideas what I might be doing wrong?
I tried updating gcc on mac, but this still happens

tonyalaribe · 2021-05-10T15:45:20Z

The rest of the error:

PabloReszczynski · 2021-05-20T18:13:18Z

Same problem! I think it may have to do with clang vs gcc

maxbrunsfeld · 2021-05-20T18:24:29Z

Yeah, I hit this too. The external scanner currently uses come C++14 features, and I guess the clang version on macOS doesn't support those by default. When the Tree-sitter CLI automatically compiles your parser, it just runs your C++ compiler with the default settings (as opposed to passing -std=c++14 or something like that), so it doesn't work.

It'd be great to make that file a little bit more portable. I'm also open to making the Tree-sitter somehow smarter about passing those flags. It just makes the compilation process a bit more complex if you have to pass C++-specific flags. @tek I'd be curious about your opinion - how important is it that the external scanner makes uses of the latest and greatest C++ features? Would it be he hard to make it compile under C++11 semantics?

tek · 2021-06-05T11:28:31Z

@maxbrunsfeld not sure, but judging from the errors here it's struggling with some c++11 features (lambdas)

archseer · 2021-06-05T13:51:26Z

I was able to build on macOS by specifying -std=c++14, however I wasn't able to get it working with the msvc equivalent on Windows (/std:c++14)

  languages\tree-sitter-haskell\src\scanner.cc(1555): error C3861: 'to_string': identifier not found
  languages\tree-sitter-haskell\src\scanner.cc(1556): error C3861: 'to_string': identifier not found
  languages\tree-sitter-haskell\src\scanner.cc(1557): error C3536: 'col': cannot be used before it is initialized
  languages\tree-sitter-haskell\src\scanner.cc(1557): error C2676: binary '+': 'std::basic_string<char,std::char_traits<char>,std::allocator<char>>' does not define this operator or a conversion to a type acceptable to the predefined operator
  languages\tree-sitter-haskell\src\scanner.cc(1557): error C2672: 'operator __surrogate_func': no matching overloaded function found
  exit code: 2

lunixbochs · 2021-06-05T17:57:02Z

@archseer I think the MSVC errors were just fixed by #38

lunixbochs · 2021-06-05T18:57:05Z

I've been triaging tree-sitter/py-tree-sitter#64 and I have tree-sitter-haskell currently building in py-tree-sitter CI on all of windows/mac/linux with a few different c++ target levels.

You can see which jobs pass from the top 3 actions here to see how passing the c++11, c++14, and c++17 flags affect a ~recent compiler on each OS: https://github.com/tree-sitter/py-tree-sitter/actions?query=branch%3Atest-haskell

I vote for tree-sitter-cli and adjacent projects (such as py-tree-sitter) to standardize on setting the same c++ support level, such as c++14 or c++17, for both MSVC and gcc/clang. That's like /std:c++17 for MSVC and -std=c++17 for gcc/clang.

compiler support

You can find compiler support here for c++14 and c++17
Clang support should generally be good.
I surveyed a couple of Linux distros:

RHEL 7 ships gcc 4.8
RHEL 8 ships gcc 8.x
Ubuntu 16.04 LTS, which hit EOL in April, ships gcc 5.4
Ubuntu 18.04 ships GCC 7.4.0.

conclusion

GCC 7 supports c++17, so think c++17 is a fairly reasonable target given these constraints. It excludes MSVC 14.0, but on Windows the MSVC version is separate from the OS version anyway so it's hopefully not too burdensome to recommend installing a current compiler there.

Once this changes, I would appreciate tree-sitter-haskell adding Windows/Mac build targets similar to py-tree-sitter, so I can leave tree-sitter-haskell in the py-tree-sitter CI without worrying about haskell breaking the py-tree-sitter build for a specific OS.

tek · 2021-06-05T22:17:52Z

sounds reasonable!

ahlinc · 2021-06-05T22:27:03Z

May be it's worth to mention in tree-sitter/tree-sitter#930

theHamsta · 2021-06-06T22:27:30Z

tree-sitter-haskell requires C++14 due to generic lambdas. But nice that the MSVC error was fixed.

archseer · 2021-06-07T01:08:31Z

Thanks for the fix @lunixbochs! I still get a failure when cross compiling to aarch64-linux with C++14:
https://github.com/helix-editor/helix/runs/2759709239

languages/tree-sitter-haskell/src/scanner.cc:87:28: error: variable 'f' has function type
...
languages/tree-sitter-haskell/src/scanner.cc:808:16: error: variable 'fa' has function type

lunixbochs · 2021-06-07T01:23:15Z

Is that aarch64-linux-android? https://github.com/rust-embedded/cross#supported-targets lists gcc 4.9. They should update that.

archseer · 2021-06-07T01:24:39Z

aarch64-unknown-linux-gnu

lunixbochs · 2021-06-07T01:25:50Z

Ah I didn't see that entry, anyway it's 4.8.2 as well. Looks like they're basing the image on Ubuntu 16.04, which is EOL: https://github.com/rust-embedded/cross/blob/master/docker/Dockerfile.aarch64-unknown-linux-gnu#L1

Even if they want to target an older glibc ABI, they should probably install a newer gcc.

nkpart · 2021-06-07T23:29:47Z

I have a similar but different problem installing on Mac, running TSInstallSync haskell from neovim. My setup is maybe different to a lot of users though. I'm using the nix-based home-manager tool to manage my user account, details:

Creating temporary directory
Extracting...
Compiling...
src/scanner.cc:2:10: fatal error: 'vector' file not found
#include <vector>
         ^~~~~~~~
1 error generated.
Error during compilation
Failed to execute the following command:
{
  cmd = "cc",
  err = "Error during compilation",
  info = "Compiling...",
  opts = {
    args = { "-o", "parser.so", "-I./src", "src/parser.c", "src/scanner.cc", "-shared", "-Os", "-lstdc++", "-fPIC" },
    cwd = "/Users/nkpart/.local/share/nvim/tree-sitter-haskell"
  }
}```

lunixbochs · 2021-06-07T23:33:56Z

You're compiling a C++ file (.cc suffix) with a C compiler

theHamsta · 2021-06-07T23:38:13Z

You're compiling a C++ file (.cc suffix) with a C compiler

Which is how nvim-treesitter installs stuff. We're compiling C and C++ and linking in one go which causes some problems for Haskell because we can't set any C or C++ standard but rely on whatever is the default. cc is either gcc or clang and they usually set the language based on the filetype (except Apple clang is again different from normal clang). @nkpart can you make sure you have a C++ runtime installed libc++ on mac or I guess libstdc++ would maybe also work.

nkpart · 2021-06-08T01:11:17Z

Thanks, I've done some digging.

As you all might know, nvim-treesitter uses https://github.com/nvim-treesitter/nvim-treesitter/blob/ddc0f1b606472b6a1ab85ee9becfd4877507627d/lua/nvim-treesitter/install.lua#L14 to figure out the compiler to use, and then this https://github.com/nvim-treesitter/nvim-treesitter/blob/ddc0f1b606472b6a1ab85ee9becfd4877507627d/lua/nvim-treesitter/shell_command_selectors.lua#L67-L75 for the argument set.

Overriding either of those things is going to be enough to make the compile work. In my case, I could run CC=clang++ vim, and then nvim-treesitter compiles scanner.cc just fine. (CC=clang still failed.)

aridgupta · 2021-06-12T23:50:33Z

I have gcc installed on mac. How do I install tree-sitter-haskell? It shows the error as mentioned by this issue.

theHamsta · 2021-06-13T00:02:57Z

@aridgupta as @nkpart mentioned nvim-treesitter will respect the CC env variable. Set the environment variable CC=gcc or in luarequire"nvim-treesitter.install".compilers = {"gcc"}

aridgupta · 2021-06-13T00:08:27Z

@theHamsta thank you. However, when I would update tree-sitter in the future, won't this fail again?

theHamsta · 2021-06-13T00:13:52Z

Not when setting require"nvim-treesitter.install".compilers = {"gcc"} in your init.vim (or lua require"nvim-treesitter.install".compilers = {"gcc"} when using vim script

farbodsz · 2021-06-16T18:20:10Z

For anyone looking through this thread facing similar issues, I was having the same error message but on Ubuntu rather than Mac:

LSB Version:	core-9.20170808ubuntu1-noarch:printing-9.20170808ubuntu1-noarch:security-9.20170808ubuntu1-noarch
Distributor ID:	Ubuntu
Description:	Ubuntu 18.04.5 LTS
Release:	18.04
Codename:	bionic

I tried gcc but interestingly, forcing tree-sitter to use clang instead of gcc fixed the problem:

require'nvim-treesitter.install'.compilers = { "clang" }

tek · 2021-06-16T21:55:24Z

made a note of it in the readme

tonyalaribe · 2021-07-24T18:59:00Z

I will close this now. require'nvim-treesitter.install'.compilers = { "gcc" } worked for me. Though I had to do
TSInstallSync haskell afterwards. Thanks!

molleweide · 2021-08-04T15:51:22Z

yo.

I'm just chiming in to say I believe I've tried all of the above but things still don't seem to work. I am personally using macos catalina.
This was also a very interesting thread to read as a beginner with tree sitter.

Pretty much all errors I get look like this src/scanner.cc:87:10: error: expected expression return [=](A a) { return f(g(a)); }; and it marks the err at the [=].

This is the last info:

last part of err

``` fatal error: too many errors emitted, stopping now [-ferror-limit=] 2 warnings and 20 errors generated. Error during compilation Failed to execute the following command: { cmd = "gcc", err = "Error during compilation", info = "Compiling...", opts = { args = { "-o", "parser.so", "-I./src", "src/parser.c", "src/scanner.cc", "-shared", "-Os", "-lstdc++", "-fPIC" }, cwd = "/Users/hjalmarjakobsson/.local/share/nvim/tree-sitter-haskell" } } ```

What other places can I look at for problem solving? Is there some other secret place or file?

I am also struggling to understand what C++-14 actually means. Does this mean I am using C++-12?:

╰ clang --version
Apple clang version 12.0.0 (clang-1200.0.32.29)
Target: x86_64-apple-darwin19.6.0
Thread model: posix
InstalledDir: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin

╰ clang++ --version
Apple clang version 12.0.0 (clang-1200.0.32.29)
Target: x86_64-apple-darwin19.6.0
Thread model: posix
InstalledDir: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin

chianuo · 2021-08-04T20:30:27Z

I can't get this to work either. I've added require'nvim-treesitter.install'.compilers = { "gcc" } to my nvim config, I've added the CC=gcc environment variable, and I still get that massive error when running TSInstall haskell. No clue what I'm doing wrong.

chianuo · 2021-08-04T20:43:30Z

@molleweide I solved it for me, maybe you're experiencing a similar issue. Basically, macOS symlinks clang to /usr/bin/gcc, so even if you install gcc from brew install gcc, and do the above configuration, you're still secretly using macOS's clang. Bloody hell, Apple.

I fixed it by linking the real gcc somewhere into my path with higher priority. cd /usr/local/bin && ln -s ./gcc-11 gcc. Now it works.

tek · 2021-08-04T20:57:21Z

made another note in the readme

tek · 2021-08-04T20:57:46Z

please share your experience so I can improve the instructions!

albohlabs · 2021-08-05T06:56:57Z

With the hint from @chianuo it works now. Awesome. 🥳

molleweide · 2021-08-05T07:23:30Z

it wooooooorks!!! 🥳 thanks @chianuo ❤️

molleweide · 2021-09-09T15:33:18Z

I just got a new M1 mac and I notice that after following the instructions in the readme again
on this new mac with M1 doing this:

ln -sf /usr/local/bin/gcc-11 /usr/local/bin/gcc

then
which gcc will still show usr/bin/gcc
because it seems that usr/local/bin/gcc-11 doesn't exist on M1 mac.
Again, I am not so comfortable with gcc so I am not sure if I explaint this in a bad order..
Could this have something to do with homebrew changing default installer location recently? hmm..

molleweide · 2021-09-09T15:38:05Z

yes it should be ln -sf /opt/homebrew/bin/gcc-11 /usr/local/bin/gcc on Macos with latest version of homebrew.

I submitted a PR with this.

bimalgaudel · 2021-12-13T00:53:50Z

I was able to build on macOS by specifying -std=c++14

@archseer Could you tell how you specified -std?

kentkwu · 2021-12-22T20:50:11Z

Here's what worked for me, on an M1 mac:

brew install gcc

At this point gcc-11 should be here:

ls /opt/homebrew/bin/ | grep gcc
...
gcc-11
...

And then just explicitly pass in gcc-11 to install.lua

require'nvim-treesitter.install'.compilers = { "gcc-11" }

This way you don't have to mess around with symlinks in /usr/local or changing the path priority.

archseer mentioned this issue Jun 5, 2021

Fails to build on Windows #37

Closed

tonyalaribe closed this as completed Jul 24, 2021

molleweide mentioned this issue Aug 4, 2021

haskell plugin module err on startup - Intel Mac (pre M1) doom-neovim/doom-nvim#70

Closed

archseer mentioned this issue Oct 11, 2021

feat: re-enable haskell syntax helix-editor/helix#823

Closed

bimalgaudel mentioned this issue Dec 24, 2021

Where should I add the following line to resolve the linked issue? VapourNvim/VapourNvim#48

Closed

Triton171 mentioned this issue Dec 26, 2021

Haskell syntax highlighting? helix-editor/helix#1384

Closed

414owen mentioned this issue Jan 2, 2022

Support c++03 #58

Merged

r7kamura mentioned this issue Aug 25, 2022

Fix: toCorrectable may throw error r7kamura/vscode-ruby-light#30

Closed

Unable to setup on mac #34

Unable to setup on mac #34

Comments

tonyalaribe commented May 10, 2021

tonyalaribe commented May 10, 2021

PabloReszczynski commented May 20, 2021

maxbrunsfeld commented May 20, 2021

tek commented Jun 5, 2021

archseer commented Jun 5, 2021 • edited

lunixbochs commented Jun 5, 2021

lunixbochs commented Jun 5, 2021 • edited

compiler support

conclusion

tek commented Jun 5, 2021

ahlinc commented Jun 5, 2021

theHamsta commented Jun 6, 2021

archseer commented Jun 7, 2021

lunixbochs commented Jun 7, 2021

archseer commented Jun 7, 2021

lunixbochs commented Jun 7, 2021 • edited

nkpart commented Jun 7, 2021

lunixbochs commented Jun 7, 2021

theHamsta commented Jun 7, 2021 • edited

nkpart commented Jun 8, 2021 • edited

aridgupta commented Jun 12, 2021 • edited

theHamsta commented Jun 13, 2021

aridgupta commented Jun 13, 2021

theHamsta commented Jun 13, 2021 • edited

farbodsz commented Jun 16, 2021 • edited

tek commented Jun 16, 2021

tonyalaribe commented Jul 24, 2021 • edited

molleweide commented Aug 4, 2021 • edited

chianuo commented Aug 4, 2021

chianuo commented Aug 4, 2021

tek commented Aug 4, 2021

tek commented Aug 4, 2021

albohlabs commented Aug 5, 2021

molleweide commented Aug 5, 2021 • edited

molleweide commented Sep 9, 2021

molleweide commented Sep 9, 2021 • edited

bimalgaudel commented Dec 13, 2021 • edited

kentkwu commented Dec 22, 2021

archseer commented Jun 5, 2021 •

edited

lunixbochs commented Jun 5, 2021 •

edited

lunixbochs commented Jun 7, 2021 •

edited

theHamsta commented Jun 7, 2021 •

edited

nkpart commented Jun 8, 2021 •

edited

aridgupta commented Jun 12, 2021 •

edited

theHamsta commented Jun 13, 2021 •

edited

farbodsz commented Jun 16, 2021 •

edited

tonyalaribe commented Jul 24, 2021 •

edited

molleweide commented Aug 4, 2021 •

edited

molleweide commented Aug 5, 2021 •

edited

molleweide commented Sep 9, 2021 •

edited

bimalgaudel commented Dec 13, 2021 •

edited