Electron 13 build failure

[jinu-jang]

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.

[Symbolk]

Yeah, I also have this problem, which is really exhausting:

I am developing a VSCode extension that depends on this native module: https://github.com/Symbolk/somanyconflicts. Previously, I have managed to conquer this problem for Node 14.16.0, Electron 12.0.4, electron-rebuild 2.3.5,node-gyp 8.1.0. However, recently VSCode upgrades its Electron to 13.1.7 (https://www.npmjs.com/package/electron-releases), and my users reported that the extension cannot run so I have to rebuild it. Then the annoying error happens again, just like the previous one about std::remove_cv_t.

I have given up it, and looking for a WebAssembly solution.

[sergei-dyshel]

ArrayBuffer API changed in newer V8 version, I have a fix in sergei-dyshel@961870e.

[gpetrov]

@maxbrunsfeld - could you incorporate the fix?

[FoamScience]

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.

[Symbolk]

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

[gpetrov]

The WASM version is slower, a real native version like the purpose of this repo is always preferred.

The repository just needs more maintenance but unfortunately @maxbrunsfeld seems to not have enough time for it, which is a real shame for such great project.

[FoamScience]

Exactly, I chose this repo over the WASM version specifically because I've read it's slower; but then I read somewhere that this is no longer the case. However a native solution is always the best.
From @Symbolk's commit, it doesn't look much work to switch back and forth between WASM and native versions, so I guess
I'll continue using the WASM version for now and wait for this repo to get updated.
Thanks!

[FoamScience]

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

So, I tried to use the WASM version myself; but LSP logs say:

Assertion failed: bad export type for `_ZNSt3__24cerrE`: undefined

Any idea on what that might mean?

[dfgordon]

Can anyone give a hint about prospects for an official fix?
As a related comment it looks like #52 could help with this sort of issue in a more general way, but from the conversation there I can't tell if it is still progressing.

[sergei-dyshel]

@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.

I don't see any point in opening CR. Maintainer seems to not be checking this repo otherwise he would fix this long ago.
Meanwhile you can create a fixed branch in your own fork and use it as a dependency in package.json. For example I have:

"dependencies": {
    # ...
	"tree-sitter": "github:sergei-dyshel/node-tree-sitter#master-next",
    # ...
}

[FoamScience]

Yes, that's what I'm doing now, still getting some undefined references but nothing a good debugging session wouldn't fix. Thanks.

…

On Mon, Dec 20, 2021, 8:43 PM Sergei Dyshel ***@***.***> wrote: @sergei-dyshel <https://github.com/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. I don't see any point in opening CR. Maintainer seems to not be checking this repo otherwise he would fix this long ago. Meanwhile you can create a fixed branch in your own fork and use it as a dependency in package.json. For example I have: "dependencies": { # ... "tree-sitter": "github:sergei-dyshel/node-tree-sitter#master-next", # ... } — Reply to this email directly, view it on GitHub <#90 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AIHAT2DOEQZUZQG5B5ZVVZTUR6BPNANCNFSM5AUV5WCA> . You are receiving this because you commented.Message ID: ***@***.***>

[dfgordon]

So, I tried to use the WASM version myself; but LSP logs say:

Assertion failed: bad export type for `_ZNSt3__24cerrE`: undefined

Any idea on what that might mean?

I was getting this also. The error went away after rebuilding the WASM using docker instead of emsdk.

[FoamScience]

@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.

I don't see any point in opening CR. Maintainer seems to not be checking this repo otherwise he would fix this long ago. Meanwhile you can create a fixed branch in your own fork and use it as a dependency in package.json. For example I have:

"dependencies": {
    # ...
	"tree-sitter": "github:sergei-dyshel/node-tree-sitter#master-next",
    # ...
}

Even with this approach (which works) I still get a:

tree_sitter_runtime_binding.node: undefined symbol: _ZN2v811ArrayBuffer3NewEPNS_7IsolateESt10shared_ptrINS_12BackingStoreEE

referring to a missing symbol definition for v8::ArrayBuffer::New(v8::Isolate*, std::shared_ptr<v8::BackingStore>)
which should be there
Shouldn't v8 be linked automatically?

[FoamScience]

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 😄