node-tree-sitter icon indicating copy to clipboard operation
node-tree-sitter copied to clipboard

Electron 13 build failure

Open jinu-jang opened this issue 3 years ago • 25 comments

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.

jinu-jang avatar Jul 20 '21 00:07 jinu-jang

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

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.

Symbolk avatar Aug 12 '21 03:08 Symbolk

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

sergei-dyshel avatar Sep 03 '21 18:09 sergei-dyshel

@maxbrunsfeld - could you incorporate the fix?

gpetrov avatar Oct 28 '21 18:10 gpetrov

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.

FoamScience avatar Dec 17 '21 19:12 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

Symbolk avatar Dec 18 '21 09:12 Symbolk

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.

gpetrov avatar Dec 18 '21 11:12 gpetrov

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 avatar Dec 18 '21 11:12 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?

FoamScience avatar Dec 18 '21 19:12 FoamScience

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.

dfgordon avatar Dec 19 '21 17:12 dfgordon

@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",
    # ...
}

sergei-dyshel avatar Dec 20 '21 19:12 sergei-dyshel

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 https://github.com/tree-sitter/node-tree-sitter/issues/90#issuecomment-998218591, or unsubscribe https://github.com/notifications/unsubscribe-auth/AIHAT2DOEQZUZQG5B5ZVVZTUR6BPNANCNFSM5AUV5WCA . You are receiving this because you commented.Message ID: @.***>

FoamScience avatar Dec 20 '21 20:12 FoamScience

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.

dfgordon avatar Dec 22 '21 16:12 dfgordon

@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 avatar Dec 23 '21 18:12 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 😄

FoamScience avatar Jan 03 '22 18:01 FoamScience

I tried this and had a similar experience, but didn't pursue and switched to WASM, which seems to work fine. Since rust and WASM bindings were moved into tree-sitter/lib it is probable that these are the bindings that will get the most consistent support from the main developers. So I join @Symbolk and suggest switch to WASM. For me the two issues with the switch were getting emscripten to produce a compatible WASM (solution is use Docker), and that I didn't know much about asynchronous functions in typescript (it's not hard to learn).

dfgordon avatar Jan 07 '22 11:01 dfgordon

Yes, exactly, plus I confirm there is no performance overhead when using the WASM version; at least for my parser.

FoamScience avatar Jan 07 '22 12:01 FoamScience

Well it is all good with the WASM build but the real native build provides 5x better performance.

A quick benchmark with parsing a html file yields:

On MacBook Pro M1 MAX:

File Size 25KB:

Parser Time
Native Tree Sitter 1.71 ms
WASM Tree Sitter 8.20 ms
Native DOM Parser 2.69 ms
Parse5 16.71 ms

File Size 200KB:

Parser Time
Native Tree Sitter 13.27 ms
WASM Tree Sitter 46 ms
Native DOM Parser 9.38 ms
Parse5 51.41 ms

On Windows 10 Pro with AMD Ryzen 7 3800X 8 Core 3.90 GHz:

File Size 25KB:

Parser Time
Native Tree Sitter 4.55 ms
WASM Tree Sitter 12.03 ms
Native DOM Parser 3.71 ms
Parse5 25.17 ms

File Size 200KB:

Parser Time
Native Tree Sitter 30.18 ms
WASM Tree Sitter 64.26 ms
Native DOM Parser 15.32 ms
Parse5 77.87 ms

So as try can see the native tree Sitter is much faster and on smaller files even faster than the native DOMParser in from the browser.

So we would really like to have a native version of the node-tree-sitter as well, next to the WASM version

However without a good rewrite to support NAPI as started in https://github.com/tree-sitter/node-tree-sitter/pull/52 Even with the current patches from https://github.com/tree-sitter/node-tree-sitter/pull/95 the current version will only work till Electron 13.

Starting from Electron 14 all non context aware modules that are not NAPI compatible, cannot be loaded any more as stated in: https://github.com/electron/electron/issues/18397

So please @maxbrunsfeld have an urgent look on this.

gpetrov avatar Jan 07 '22 13:01 gpetrov

tree-sitter doesn't build alongside the latest version of VSCode there error i get is:

error User\workspace\vscode\node_modules\tree-sitter: Command failed.
Exit code: 1
Command: prebuild-install || node-gyp rebuild
Arguments:
Directory: User\workspace\vscode\node_modules\tree-sitter
Output:
User\workspace\vscode\node_modules\node-abi\index.js:36
  throw new Error('Could not detect abi for version ' + target + ' and runtime ' + runtime + '.  Updating "node-abi" might help solve this issue if it is a new release of ' + runtime)
  ^

Error: Could not detect abi for version 17.4.0 and runtime electron.  Updating "node-abi" might help solve this issue if it is a new release of electron
    at getAbi (User\workspace\vscode\node_modules\node-abi\index.js:36:9)
    at module.exports (User\workspace\vscode\node_modules\prebuild-install\rc.js:52:57)
    at Object.<anonymous> (User\workspace\vscode\node_modules\prebuild-install\bin.js:8:25)
    at Module._compile (node:internal/modules/cjs/loader:1103:14)
    at Object.Module._extensions..js (node:internal/modules/cjs/loader:1155:10)
    at Module.load (node:internal/modules/cjs/loader:981:32)
    at Function.Module._load (node:internal/modules/cjs/loader:822:12)
    at Function.executeUserEntryPoint [as runMain] (node:internal/modules/run_main:77:12)
    at node:internal/main/run_main_module:17:47

User\workspace\vscode\node_modules\tree-sitter>if not defined npm_config_node_gyp (node "C:\Program Files\nodejs\node_modules\npm\bin\node-gyp-bin\\..\..\node_modules\node-gyp\bin\node-gyp.js" rebuild )  else (node "" rebuild )
gyp info it worked if it ends with ok
gyp info using [email protected]
gyp info using [email protected] | win32 | x64
gyp info find Python using Python version 3.10.4 found at "User\AppData\Local\Microsoft\WindowsApps\PythonSoftwareFoundation.Python.3.10_qbz5n2kfra8p0\python.exe"
gyp info find VS using VS2019 (16.11.32228.343) found at:
gyp info find VS "C:\Program Files (x86)\Microsoft Visual Studio\2019\BuildTools"
gyp info find VS run with --verbose for detailed information
gyp info spawn User\AppData\Local\Microsoft\WindowsApps\PythonSoftwareFoundation.Python.3.10_qbz5n2kfra8p0\python.exe
gyp info spawn args [
gyp info spawn args   'user\\AppData\\Roaming\\nvm\\v16.14.0\\node_modules\\npm\\node_modules\\node-gyp\\gyp\\gyp_main.py',
gyp info spawn args   'binding.gyp',
gyp info spawn args   '-f',
gyp info spawn args   'msvs',
gyp info spawn args   '-I',
gyp info spawn args   'user\\workspace\\vscode\\node_modules\\tree-sitter\\build\\config.gypi',
gyp info spawn args   '-I',
gyp info spawn args   'user\\AppData\\Roaming\\nvm\\v16.14.0\\node_modules\\npm\\node_modules\\node-gyp\\addon.gypi',
gyp info spawn args   '-I',
gyp info spawn args   'user\\AppData\\Local\\node-gyp\\Cache\\17.4.0\\include\\node\\common.gypi',
gyp info spawn args   '-Dlibrary=shared_library',
gyp info spawn args   '-Dvisibility=default',
gyp info spawn args   '-Dnode_root_dir=user\\AppData\\Local\\node-gyp\\Cache\\17.4.0',
gyp info spawn args   '-Dnode_gyp_dir=user\\AppData\\Roaming\\nvm\\v16.14.0\\node_modules\\npm\\node_modules\\node-gyp',
gyp info spawn args   '-Dnode_lib_file=user\\\AppData\\\\Local\\\\node-gyp\\\\Cache\\\\17.4.0\\\\<(target_arch)\\\\node.lib',
gyp info spawn args   '-Dmodule_root_dir=user\\workspace\\vscode\\node_modules\\tree-sitter',
gyp info spawn args   '-Dnode_engine=v8',
gyp info spawn args   '--depth=.',
gyp info spawn args   '--no-parallel',
gyp info spawn args   '--generator-output',
gyp info spawn args   'user\\workspace\\vscode\\node_modules\\tree-sitter\\build',
gyp info spawn args   '-Goutput_dir=.'
gyp info spawn args ]
gyp info spawn C:\Program Files (x86)\Microsoft Visual Studio\2019\BuildTools\MSBuild\Current\Bin\MSBuild.exe
gyp info spawn args [
User\workspace\vscode\node_modules\tree-sitter\src\conversions.cc(32,118): error C2661: 'Nan::Set': no overloaded function takes 2 arguments [User\workspace\vscode\node_modules\tree-sitter\build\tree_sitter_runtime_binding.vcxproj]
gyp ERR! build error
gyp ERR! stack Error: `C:\Program Files (x86)\Microsoft Visual Studio\2019\BuildTools\MSBuild\Current\Bin\MSBuild.exe` failed with exit code: 1
gyp ERR! stack     at ChildProcess.onExit (User\AppData\Roaming\nvm\v16.14.0\node_modules\npm\node_modules\node-gyp\lib\build.js:194:23)
gyp ERR! stack     at ChildProcess.emit (node:events:520:28)
gyp ERR! stack     at Process.ChildProcess._handle.onexit (node:internal/child_process:291:12)
gyp ERR! System Windows_NT 10.0.22000gyp ERR! command "C:\\Program Files\\nodejs\\node.exe" "C:\\Program Files\\nodejs\\node_modules\\npm\\node_modules\\node-gyp\\bin\\node-gyp.js" "rebuild"
gyp ERR! cwd User\workspace\vscode\node_modules\tree-sitter

jasonwilliams avatar Apr 18 '22 18:04 jasonwilliams

Hi, any update on this?

Sarrus1 avatar Aug 11 '22 10:08 Sarrus1

@maxbrunsfeld is this repo dead? It hasn’t built against node for some time now

jasonwilliams avatar Oct 07 '22 10:10 jasonwilliams

@FoamScience

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>)

I think I've found the symbol for New in the electron (13.6.9) binary:

nm -C node_modules/electron/dist/electron | grep 'v8::ArrayBuffer::New'
0000000002caa680 T v8::ArrayBuffer::NewBackingStore(v8::Isolate*, unsigned long)
0000000002caa790 T v8::ArrayBuffer::NewBackingStore(void*, unsigned long, void (*)(void*, unsigned long, void*), void*)
0000000002caa3c0 T v8::ArrayBuffer::New(v8::Isolate*, unsigned long)
0000000002caa4b0 T v8::ArrayBuffer::New(v8::Isolate*, std::__1::shared_ptr<v8::BackingStore>)

The last of these seems to be what is needed. Unfortunately, it seems to be using the LLVM runtime.

I guess if you can run prebuild against libc++, it might solve this problem.

bencwallace avatar Jan 08 '23 18:01 bencwallace

Oh, that it is actually good news; Thanks! I have switched to WASM builds since, and they work - I can't remember if this was the only error but if I find time, I'll probably go back and try the native version

@FoamScience

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>)

I think I've found the symbol for New in the electron (13.6.9) binary:

nm -C node_modules/electron/dist/electron | grep 'v8::ArrayBuffer::New'
0000000002caa680 T v8::ArrayBuffer::NewBackingStore(v8::Isolate*, unsigned long)
0000000002caa790 T v8::ArrayBuffer::NewBackingStore(void*, unsigned long, void (*)(void*, unsigned long, void*), void*)
0000000002caa3c0 T v8::ArrayBuffer::New(v8::Isolate*, unsigned long)
0000000002caa4b0 T v8::ArrayBuffer::New(v8::Isolate*, std::__1::shared_ptr<v8::BackingStore>)

The last of these seems to be what is needed. Unfortunately, it seems to be using the LLVM runtime.

I guess if you can run prebuild against libc++, it might solve this problem.

FoamScience avatar Jan 08 '23 19:01 FoamScience

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 avatar Jan 08 '23 19:01 bencwallace

I spent some time trying to figure this out, and all I can say is it's still an issue, you can't compile node-tree-sitter for Electron 13+ on Windows, but it seems to work on Ubuntu and macOS. The only thing I managed to figure out is that #95 didn't work as expected (see https://github.com/tree-sitter/node-tree-sitter/pull/95#issuecomment-1603168400 ).

The CI now tests this exhaustively by running these commands:

npx prebuild -t 10.0.0 -t 12.0.0 -t 14.0.0 -t 16.0.0 -t 18.0.0 -t 20.0.0
npx prebuild -r electron -t 3.0.0 -t 4.0.0 -t 5.0.0 -t 6.0.0 -t 7.0.0 -t 8.0.0 -t 9.0.0 -t 10.0.0 -t 11.0.0 -t 12.0.0 -t 13.0.0 -t 14.0.0 -t 15.0.0 -t 16.0.0 -t 17.0.0 -t 18.0.0 -t 19.0.0 -t 20.0.0 -t 21.0.0 -t 22.0.0 -t 23.0.0 -t 24.0.0 -t 25.0.0

and we can see that when running prebuild under Node 16, 18 or 20 it successfully compiles on Ubuntu and macOS for Node 10, 12, 14, 16, 18 and 20 and Electron 3-25. On Windows it will compile for all the previously mentioned Node versions but it will only compile for Electron 3-12 and produce this error on Electron 13:

prebuild info build Preparing to prebuild [email protected] for electron 13.0.0 on win32-x64 using node-gyp
gyp info find Python using Python version 3.7.9 found at "C:\hostedtoolcache\windows\Python\3.7.9\x64\python3.exe"
gyp http GET https://electronjs.org/headers/v13.0.0/node-v13.0.0-headers.tar.gz
gyp http 200 https://artifacts.electronjs.org/headers/v13.0.0/node-v13.0.0-headers.tar.gz?force_headers_dist=1
gyp http GET https://electronjs.org/headers/v13.0.0/SHASUMS256.txt
gyp http GET https://electronjs.org/headers/v13.0.0/win-x64/node.lib
gyp http 200 https://artifacts.electronjs.org/headers/v13.0.0/SHASUMS256.txt?force_headers_dist=1
gyp http 200 https://artifacts.electronjs.org/headers/v13.0.0/win-x64/node.lib?force_headers_dist=1
gyp info find VS using VS2019 (16.11.33529.622) found at:
gyp info find VS "C:\Program Files (x86)\Microsoft Visual Studio\2019\Enterprise"
gyp info find VS run with --verbose for detailed information
gyp info spawn C:\hostedtoolcache\windows\Python\3.7.9\x64\python3.exe
gyp info spawn args [
gyp info spawn args   'D:\\a\\node-tree-sitter\\node-tree-sitter\\node_modules\\node-gyp\\gyp\\gyp_main.py',
gyp info spawn args   'binding.gyp',
gyp info spawn args   '-f',
gyp info spawn args   'msvs',
gyp info spawn args   '-I',
gyp info spawn args   'D:\\a\\node-tree-sitter\\node-tree-sitter\\build\\config.gypi',
gyp info spawn args   '-I',
gyp info spawn args   'D:\\a\\node-tree-sitter\\node-tree-sitter\\node_modules\\node-gyp\\addon.gypi',
gyp info spawn args   '-I',
gyp info spawn args   'C:\\Users\\RUNNER~1\\AppData\\Local\\Temp\\prebuild\\electron\\13.0.0\\include\\node\\common.gypi',
gyp info spawn args   '-Dlibrary=shared_library',
gyp info spawn args   '-Dvisibility=default',
gyp info spawn args   '-Dnode_root_dir=C:\\Users\\RUNNER~1\\AppData\\Local\\Temp\\prebuild\\electron\\13.0.0',
gyp info spawn args   '-Dnode_gyp_dir=D:\\a\\node-tree-sitter\\node-tree-sitter\\node_modules\\node-gyp',
gyp info spawn args   '-Dnode_lib_file=C:\\\\Users\\\\RUNNER~1\\\\AppData\\\\Local\\\\Temp\\\\prebuild\\\\electron\\\\13.0.0\\\\<(target_arch)\\\\node.lib',
gyp info spawn args   '-Dmodule_root_dir=D:\\a\\node-tree-sitter\\node-tree-sitter',
gyp info spawn args   '-Dnode_engine=v8',
gyp info spawn args   '--depth=.',
gyp info spawn args   '--no-parallel',
gyp info spawn args   '--generator-output',
gyp info spawn args   'D:\\a\\node-tree-sitter\\node-tree-sitter\\build',
gyp info spawn args   '-Goutput_dir=.'
gyp info spawn args ]
gyp info spawn C:\Program Files (x86)\Microsoft Visual Studio\2019\Enterprise\MSBuild\Current\Bin\MSBuild.exe
gyp info spawn args [
gyp info spawn args   'build/binding.sln',
gyp info spawn args   '/clp:Verbosity=minimal',
gyp info spawn args   '/nologo',
gyp info spawn args   '/p:Configuration=Release;Platform=x64'
gyp info spawn args ]
Building the projects in this solution one at a time. To enable parallel build, please add the "-m" switch.
  lib.c
D:\a\node-tree-sitter\node-tree-sitter\vendor\tree-sitter\lib\src\query.c(3665,51): warning C4018: '>': signed/unsigned mismatch [D:\a\node-tree-sitter\node-tree-sitter\build\tree_sitter.vcxproj]
  win_delay_load_hook.cc
  tree_sitter.vcxproj -> D:\a\node-tree-sitter\node-tree-sitter\build\Release\\tree_sitter.lib
  binding.cc
C:\Users\runneradmin\AppData\Local\Temp\prebuild\electron\13.0.0\include\node\v8.h(1670,55): warning C4996: 'v8::Module::ResolveCallback': Use ResolveModuleCallback [D:\a\node-tree-sitter\node-tree-sitter\build\tree_sitter_runtime_binding.vcxproj]
C:\Users\runneradmin\AppData\Local\Temp\prebuild\electron\13.0.0\include\node\v8.h(8652,7): warning C4996: 'v8::HostImportModuleDynamicallyCallback': Use HostImportModuleDynamicallyWithImportAssertionsCallback instead [D:\a\node-tree-sitter\node-tree-sitter\build\tree_sitter_runtime_binding.vcxproj]
  conversions.cc
C:\Users\runneradmin\AppData\Local\Temp\prebuild\electron\13.0.0\include\node\v8.h(1670,55): warning C4996: 'v8::Module::ResolveCallback': Use ResolveModuleCallback [D:\a\node-tree-sitter\node-tree-sitter\build\tree_sitter_runtime_binding.vcxproj]
C:\Users\runneradmin\AppData\Local\Temp\prebuild\electron\13.0.0\include\node\v8.h(8652,7): warning C4996: 'v8::HostImportModuleDynamicallyCallback': Use HostImportModuleDynamicallyWithImportAssertionsCallback instead [D:\a\node-tree-sitter\node-tree-sitter\build\tree_sitter_runtime_binding.vcxproj]
  language.cc
C:\Users\runneradmin\AppData\Local\Temp\prebuild\electron\13.0.0\include\node\v8.h(1670,55): warning C4996: 'v8::Module::ResolveCallback': Use ResolveModuleCallback [D:\a\node-tree-sitter\node-tree-sitter\build\tree_sitter_runtime_binding.vcxproj]
C:\Users\runneradmin\AppData\Local\Temp\prebuild\electron\13.0.0\include\node\v8.h(8652,7): warning C4996: 'v8::HostImportModuleDynamicallyCallback': Use HostImportModuleDynamicallyWithImportAssertionsCallback instead [D:\a\node-tree-sitter\node-tree-sitter\build\tree_sitter_runtime_binding.vcxproj]
  logger.cc
C:\Users\runneradmin\AppData\Local\Temp\prebuild\electron\13.0.0\include\node\v8.h(1670,55): warning C4996: 'v8::Module::ResolveCallback': Use ResolveModuleCallback [D:\a\node-tree-sitter\node-tree-sitter\build\tree_sitter_runtime_binding.vcxproj]
C:\Users\runneradmin\AppData\Local\Temp\prebuild\electron\13.0.0\include\node\v8.h(8652,7): warning C4996: 'v8::HostImportModuleDynamicallyCallback': Use HostImportModuleDynamicallyWithImportAssertionsCallback instead [D:\a\node-tree-sitter\node-tree-sitter\build\tree_sitter_runtime_binding.vcxproj]
  node.cc
C:\Users\runneradmin\AppData\Local\Temp\prebuild\electron\13.0.0\include\node\v8.h(1670,55): warning C4996: 'v8::Module::ResolveCallback': Use ResolveModuleCallback [D:\a\node-tree-sitter\node-tree-sitter\build\tree_sitter_runtime_binding.vcxproj]
C:\Users\runneradmin\AppData\Local\Temp\prebuild\electron\13.0.0\include\node\v8.h(8652,7): warning C4996: 'v8::HostImportModuleDynamicallyCallback': Use HostImportModuleDynamicallyWithImportAssertionsCallback instead [D:\a\node-tree-sitter\node-tree-sitter\build\tree_sitter_runtime_binding.vcxproj]
  parser.cc
C:\Users\runneradmin\AppData\Local\Temp\prebuild\electron\13.0.0\include\node\v8.h(1670,55): warning C4996: 'v8::Module::ResolveCallback': Use ResolveModuleCallback [D:\a\node-tree-sitter\node-tree-sitter\build\tree_sitter_runtime_binding.vcxproj]
C:\Users\runneradmin\AppData\Local\Temp\prebuild\electron\13.0.0\include\node\v8.h(8652,7): warning C4996: 'v8::HostImportModuleDynamicallyCallback': Use HostImportModuleDynamicallyWithImportAssertionsCallback instead [D:\a\node-tree-sitter\node-tree-sitter\build\tree_sitter_runtime_binding.vcxproj]
  query.cc
C:\Users\runneradmin\AppData\Local\Temp\prebuild\electron\13.0.0\include\node\v8.h(1670,55): warning C4996: 'v8::Module::ResolveCallback': Use ResolveModuleCallback [D:\a\node-tree-sitter\node-tree-sitter\build\tree_sitter_runtime_binding.vcxproj]
C:\Users\runneradmin\AppData\Local\Temp\prebuild\electron\13.0.0\include\node\v8.h(8652,7): warning C4996: 'v8::HostImportModuleDynamicallyCallback': Use HostImportModuleDynamicallyWithImportAssertionsCallback instead [D:\a\node-tree-sitter\node-tree-sitter\build\tree_sitter_runtime_binding.vcxproj]
  tree.cc
C:\Users\runneradmin\AppData\Local\Temp\prebuild\electron\13.0.0\include\node\v8.h(1670,55): warning C4996: 'v8::Module::ResolveCallback': Use ResolveModuleCallback [D:\a\node-tree-sitter\node-tree-sitter\build\tree_sitter_runtime_binding.vcxproj]
C:\Users\runneradmin\AppData\Local\Temp\prebuild\electron\13.0.0\include\node\v8.h(8652,7): warning C4996: 'v8::HostImportModuleDynamicallyCallback': Use HostImportModuleDynamicallyWithImportAssertionsCallback instead [D:\a\node-tree-sitter\node-tree-sitter\build\tree_sitter_runtime_binding.vcxproj]
  tree_cursor.cc
C:\Users\runneradmin\AppData\Local\Temp\prebuild\electron\13.0.0\include\node\v8.h(1670,55): warning C4996: 'v8::Module::ResolveCallback': Use ResolveModuleCallback [D:\a\node-tree-sitter\node-tree-sitter\build\tree_sitter_runtime_binding.vcxproj]
C:\Users\runneradmin\AppData\Local\Temp\prebuild\electron\13.0.0\include\node\v8.h(8652,7): warning C4996: 'v8::HostImportModuleDynamicallyCallback': Use HostImportModuleDynamicallyWithImportAssertionsCallback instead [D:\a\node-tree-sitter\node-tree-sitter\build\tree_sitter_runtime_binding.vcxproj]
  util.cc
C:\Users\runneradmin\AppData\Local\Temp\prebuild\electron\13.0.0\include\node\v8.h(1670,55): warning C4996: 'v8::Module::ResolveCallback': Use ResolveModuleCallback [D:\a\node-tree-sitter\node-tree-sitter\build\tree_sitter_runtime_binding.vcxproj]
C:\Users\runneradmin\AppData\Local\Temp\prebuild\electron\13.0.0\include\node\v8.h([865](https://github.com/tree-sitter/node-tree-sitter/actions/runs/5349619904/jobs/9701093616?pr=150#step:10:866)2,7): warning C4996: 'v8::HostImportModuleDynamicallyCallback': Use HostImportModuleDynamicallyWithImportAssertionsCallback instead [D:\a\node-tree-sitter\node-tree-sitter\build\tree_sitter_runtime_binding.vcxproj]
D:\a\node-tree-sitter\node-tree-sitter\src\util.cc(18,20): warning C4996: 'v8::Object::CreationContext': Use MaybeLocal<Context> GetCreationContext() [D:\a\node-tree-sitter\node-tree-sitter\build\tree_sitter_runtime_binding.vcxproj]
  win_delay_load_hook.cc
     Creating library D:\a\node-tree-sitter\node-tree-sitter\build\Release\tree_sitter_runtime_binding.lib and object D:\a\node-tree-sitter\node-tree-sitter\build\Release\tree_sitter_runtime_binding.exp
conversions.obj : error LNK2019: unresolved external symbol "__declspec(dllimport) public: static class v8::Local<class v8::ArrayBuffer> __cdecl v8::ArrayBuffer::New(class v8::Isolate *,class std::shared_ptr<class v8::BackingStore>)" (__imp_?New@ArrayBuffer@v8@@SA?AV?$Local@VArrayBuffer@v8@@@2@PEAVIsolate@2@V?$shared_ptr@VBackingStore@v8@@@std@@@Z) referenced in function "void __cdecl node_tree_sitter::InitConversions(class v8::Local<class v8::Object>)" (?InitConversions@node_tree_sitter@@YAXV?$Local@VObject@v8@@@v8@@@Z) [D:\a\node-tree-sitter\node-tree-sitter\build\tree_sitter_runtime_binding.vcxproj]
node.obj : error LNK2001: unresolved external symbol "__declspec(dllimport) public: static class v8::Local<class v8::ArrayBuffer> __cdecl v8::ArrayBuffer::New(class v8::Isolate *,class std::shared_ptr<class v8::BackingStore>)" (__imp_?New@ArrayBuffer@v8@@SA?AV?$Local@VArrayBuffer@v8@@@2@PEAVIsolate@2@V?$shared_ptr@VBackingStore@v8@@@std@@@Z) [D:\a\node-tree-sitter\node-tree-sitter\build\tree_sitter_runtime_binding.vcxproj]
    Hint on symbols that are defined and could potentially match:
      "__declspec(dllimport) public: static class v8::Local<class v8::Array> __cdecl v8::Array::New(class v8::Isolate *,int)" (__imp_?New@Array@v8@@SA?AV?$Local@VArray@v8@@@2@PEAVIsolate@2@H@Z)
      "__declspec(dllimport) public: static class v8::Local<class v8::External> __cdecl v8::External::New(class v8::Isolate *,void *)" (__imp_?New@External@v8@@SA?AV?$Local@VExternal@v8@@@2@PEAVIsolate@2@PEAX@Z)
      "__declspec(dllimport) public: static class v8::Local<class v8::FunctionTemplate> __cdecl v8::FunctionTemplate::New(class v8::Isolate *,void (__cdecl*)(class v8::FunctionCallbackInfo<class v8::Value> const &),class v8::Local<class v8::Value>,class v8::Local<class v8::Signature>,int,enum v8::ConstructorBehavior,enum v8::SideEffectType,class v8::CFunction const *)" (__imp_?New@FunctionTemplate@v8@@SA?AV?$Local@VFunctionTemplate@v8@@@2@PEAVIsolate@2@P6AXAEBV?$FunctionCallbackInfo@VValue@v8@@@2@@ZV?$Local@VValue@v8@@@2@V?$Local@VSignature@v8@@@2@HW4ConstructorBehavior@2@W4SideEffectType@2@PEBVCFunction@2@@Z)
      "__declspec(dllimport) public: static class v8::Local<class v8::Integer> __cdecl v8::Integer::New(class v8::Isolate *,int)" (__imp_?New@Integer@v8@@SA?AV?$Local@VInteger@v8@@@2@PEAVIsolate@2@H@Z)
      "__declspec(dllimport) public: static class v8::Local<class v8::Number> __cdecl v8::Number::New(class v8::Isolate *,double)" (__imp_?New@Number@v8@@SA?AV?$Local@VNumber@v8@@@2@PEAVIsolate@2@N@Z)
      "__declspec(dllimport) public: static class v8::Local<class v8::Object> __cdecl v8::Object::New(class v8::Isolate *)" (__imp_?New@Object@v8@@SA?AV?$Local@VObject@v8@@@2@PEAVIsolate@2@@Z)
      "__declspec(dllimport) public: static class v8::Local<class v8::ObjectTemplate> __cdecl v8::ObjectTemplate::New(class v8::Isolate *,class v8::Local<class v8::FunctionTemplate>)" (__imp_?New@ObjectTemplate@v8@@SA?AV?$Local@VObjectTemplate@v8@@@2@PEAVIsolate@2@V?$Local@VFunctionTemplate@v8@@@2@@Z)
      "__declspec(dllimport) public: static class v8::Local<class v8::Signature> __cdecl v8::Signature::New(class v8::Isolate *,class v8::Local<class v8::FunctionTemplate>)" (__imp_?New@Signature@v8@@SA?AV?$Local@VSignature@v8@@@2@PEAVIsolate@2@V?$Local@VFunctionTemplate@v8@@@2@@Z)
      "__declspec(dllimport) public: static class v8::Local<class v8::Uint32Array> __cdecl v8::Uint32Array::New(class v8::Local<class v8::ArrayBuffer>,unsigned __int64,unsigned __int64)" (__imp_?New@Uint32Array@v8@@SA?AV?$Local@VUint32Array@v8@@@2@V?$Local@VArrayBuffer@v8@@@2@_K1@Z)
conversions.obj : error LNK2019: unresolved external symbol "__declspec(dllimport) public: static class std::unique_ptr<class v8::BackingStore,struct std::default_delete<class v8::BackingStore> > __cdecl v8::ArrayBuffer::NewBackingStore(void *,unsigned __int64,void (__cdecl*)(void *,unsigned __int64,void *),void *)" (__imp_?NewBackingStore@ArrayBuffer@v8@@SA?AV?$unique_ptr@VBackingStore@v8@@U?$default_delete@VBackingStore@v8@@@std@@@std@@PEAX_KP6AX010@Z0@Z) referenced in function "void __cdecl node_tree_sitter::InitConversions(class v8::Local<class v8::Object>)" (?InitConversions@node_tree_sitter@@YAXV?$Local@VObject@v8@@@v8@@@Z) [D:\a\node-tree-sitter\node-tree-sitter\build\tree_sitter_runtime_binding.vcxproj]
node.obj : error LNK2001: unresolved external symbol "__declspec(dllimport) public: static class std::unique_ptr<class v8::BackingStore,struct std::default_delete<class v8::BackingStore> > __cdecl v8::ArrayBuffer::NewBackingStore(void *,unsigned __int64,void (__cdecl*)(void *,unsigned __int64,void *),void *)" (__imp_?NewBackingStore@ArrayBuffer@v8@@SA?AV?$unique_ptr@VBackingStore@v8@@U?$default_delete@VBackingStore@v8@@@std@@@std@@PEAX_KP6AX010@Z0@Z) [D:\a\node-tree-sitter\node-tree-sitter\build\tree_sitter_runtime_binding.vcxproj]
prebuild ERR! build error 
D:\a\node-tree-sitter\node-tree-sitter\build\Release\tree_sitter_runtime_binding.node : fatal error LNK1120: 2 unresolved externals [D:\a\node-tree-sitter\node-tree-sitter\build\tree_sitter_runtime_binding.vcxproj]
prebuild ERR! stack Error: `C:\Program Files (x86)\Microsoft Visual Studio\2019\Enterprise\MSBuild\Current\Bin\MSBuild.exe` failed with exit code: 1
prebuild ERR! stack     at ChildProcess.onExit (D:\a\node-tree-sitter\node-tree-sitter\node_modules\node-gyp\lib\build.js:203:23)
prebuild ERR! stack     at ChildProcess.emit (node:events:511:28)
prebuild ERR! stack     at ChildProcess._handle.onexit (node:internal/child_process:293:12)
prebuild ERR! not ok 
prebuild ERR! build Error: `C:\Program Files (x86)\Microsoft Visual Studio\2019\Enterprise\MSBuild\Current\Bin\MSBuild.exe` failed with exit code: 1
prebuild ERR! build     at ChildProcess.onExit (D:\a\node-tree-sitter\node-tree-sitter\node_modules\node-gyp\lib\build.js:203:23)
prebuild ERR! build     at ChildProcess.emit (node:events:511:28)
prebuild ERR! build     at ChildProcess._handle.onexit (node:internal/child_process:293:12)

which is saying the functions v8::ArrayBuffer::New and v8::ArrayBuffer::NewBackingStore don't exist (couldn't be found by the linker). Electron 13+ uses Node 14.16.0, NODE_MODULE_VERSION 89 and uses V8 9.1. NewBackingStore was added in V8 8.0.22 https://github.com/v8/v8/commit/bba5f1f43d59cf06e6043eb94d689021cc94a4e2 and v8::ArrayBuffer::New way before then, at least in V8 v3 https://github.com/v8/v8/commit/44f2d534b162edc5da6f03d73a44c993b7dcdeb3 . Also, the code it's failing on also uses BackingStore::EmptyDeleter which was added in V8 v8.3.9 https://github.com/v8/v8/commit/5cf02f0f207c05cebce74b1a8f2d0fe2accc7df6 , but there's no error about that, so these must be removed from Electron's V8 somehow.

verhovsky avatar Jun 22 '23 19:06 verhovsky

This should be fixed with node-tree-sitter v0.20.4. If someone could confirm or re-open the issue if it's still not fixed, that would be great.

verhovsky avatar Jun 24 '23 21:06 verhovsky