node-tree-sitter: Electron 13 build failure

Anyone tried to build for Electron 13?

Trying it with prebuild -r electron -t 13.0.1 leads to errors such as tree-sitter\src\node.cc(32,129): error C2661: 'v8::ArrayBuffer::New': no overloaded function takes 3 arguments tree-sitter\src\node.cc(36,42): error C3536: 'js_transfer_buffer': cannot be used before it is initialized tree-sitter\src\node.cc(36,69): error C2665: 'v8::Uint32Array::New': none of the 2 overloads could convert all the argument types

I’m aware of #83, and the problems described above happen after changing binding.gyp to following

      "cflags": [
        "-std=c++17",
      ],
      'xcode_settings': {
        'CLANG_CXX_LANGUAGE_STANDARD': 'c++17',
      },

This does not happen when building for other versions of electron or node.

About this issue

Original URL
State: open
Created 3 years ago
Reactions: 1
Comments: 25 (3 by maintainers)

Most upvoted comments

Any update on this? @sergei-dyshel Could you please PR the fix to this repo? I also need to use Tree-Sitter in a VSCode extension, and limiting users to vscode-1.56.x is not wise.

Hi, I suggest to use WASM version, like what I have done: https://github.com/Symbolk/somanyconflicts

Symbolk on Dec 18, 2021

Please let me know if you end up with a reasonably clean solution.

This blog post contains an interesting deep dive into a similar issue that the author encountered when moving to chromium 90.0.4415.0. It seems Electron 13 was the first version to use a version of chromium greater than or equal to that. Their ultimate suggestion is similar to @gpetrov’s (use NAPI).

bencwallace on Jan 8, 2023

Hi, any update on this?

Sarrus1 on Aug 11, 2022

Happy new year guys @sergei-dyshel When I use your repo for my vscode extension, I can rebuild modules for electron 13 But at runtime, VSCode says there is a symbol lookup error concerning v8::ArrayBuffer::New(v8::Isolate*, std::shared_ptr<v8::BackingStore>) (undefined).

nm says it’s not defined too, but I guess that’s OK as it seems VSCode loads libraries at runtime (there are a lot of undefined symbols from v8 at this point). Also, note that nm does not know a candidate library to look for the symbol in:

nm -C ./node_modules/tree-sitter/build/Release/obj.target/tree_sitter_runtime_binding.node | grep ArrayBuffer::New
                 U v8::ArrayBuffer::NewBackingStore(void*, unsigned long, void (*)(void*, unsigned long, void*), void*)
                 U v8::ArrayBuffer::New(v8::Isolate*, std::shared_ptr<v8::BackingStore>)

ldd does not mention anything about libv8 or libnode.a:

ldd ./node_modules/tree-sitter/build/Release/obj.target/tree_sitter_runtime_binding.node
	linux-vdso.so.1 (0x00007ffc2c1ad000)
	libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007f59d9b3a000)
	libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f59d9b17000)
	libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f59d9925000)
	libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f59d97d6000)
	/lib64/ld-linux-x86-64.so.2 (0x00007f59d9da5000)
	libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007f59d97b9000)

Anyone has experienced this before? Any help is much appreciated as it’s driving me crazy 😄

FoamScience on Jan 3, 2022

ArrayBuffer API changed in newer V8 version, I have a fix in https://github.com/sergei-dyshel/node-tree-sitter/commit/961870e07d395c8000a27051b01e01d6cecf7e9b.

sergei-dyshel on Sep 3, 2021