VTK 9.5.0 WebAssembly 64-bit build fails with BigInt conversion error

Support
1

Hello, I’m trying to build VTK 9.5.0 with WebAssembly 64-bit support following the official documentation, but I’m encountering a BigInt conversion error during the build process.

Special Note: Initially, the build was using Emscripten’s bundled Node.js, so I modified the .emscripten file to point to my system’s Node.js v23.8.0 instead.

Environment:

  • VTK: 9.5.0
  • CMake: 3.31
  • Emscripten: 4.0.3
  • Node.js: v23.8.0
  • OS: Windows 11
  • Build system: Ninja

Build Configuration:

bash

emcmake cmake \
    -S .. \
    -B . \
    -G "Ninja" \
    -DCMAKE_BUILD_TYPE=Release \
    -DBUILD_SHARED_LIBS:BOOL=OFF \
    -DVTK_WEBASSEMBLY_THREADS:BOOL=ON \
    -DVTK_WEBASSEMBLY_EXCEPTIONS:BOOL=ON \
    -DVTK_WEBASSEMBLY_64_BIT:BOOL=ON

Error: During the build, when trying to generate the wrap hierarchy for VTK::CommonCore, I get:

[1134/4962] Generating the wrap hierarchy for VTK::CommonCore
FAILED: lib/vtk-9.5/hierarchy/VTK/vtkCommonCore-hierarchy.txt
...
TypeError: Cannot convert a BigInt value to a number
    at Object. (D:\dev\vtk-07-08\VTK-9.5.0\build\bin\vtkWrapHierarchy-9.5.js:1:6880)
    at Module._compile (node:internal/modules/cjs/loader:1734:14)
    ...
Node.js v23.8.0

The build system is trying to run vtkWrapHierarchy-9.5.js with Node.js using the --experimental-wasm-memory64 flag, but it fails with a BigInt conversion error.

Question: Is this a known issue with VTK 9.5.0’s WebAssembly 64-bit build? The documentation mentions 64-bit support, but it seems the build tools themselves have issues running in 64-bit mode. Should the build tools (like vtkWrapHierarchy) be compiled in 32-bit mode while keeping the actual VTK libraries in 64-bit?

Any guidance would be greatly appreciated. Thank you!

2

Please use node >= 24.0.0. See Building VTK | VTK.wasm for a complete guide.

1 Like
3

Thank you so much! I really appreciate your help.

5

Thank you for your guidance - I successfully built VTK with 64-bit following your instructions. I really appreciate your help. However, when I tried to build the cone example, I encountered an issue.

I successfully configured the build using emcmake with these flags:

-DCMAKE_C_FLAGS="-sMEMORY64" -DCMAKE_CXX_FLAGS="-sMEMORY64"

But when I run cmake --build build, I get the following error. How can I resolve this?

PS D:\dev\vtk-07-09\Examples\Emscripten\Cxx\HsCone> cmake --build build
[1/1] Linking CXX executable D:\dev\vtk-07-09\Examples\docs\public\demo\cpp-app-1\main.js
FAILED: D:/dev/vtk-07-09/Examples/docs/public/demo/cpp-app-1/main.js
C:\WINDOWS\system32\cmd.exe /C "cd . && D:\dev\vtk-07-09\emsdk\upstream\emscripten\em++.bat -sMEMORY64 -g -lembind -sALLOW_MEMORY_GROWTH=1 -sSINGLE_FILE=1 -sASSERTIONS=1 -O0 -g3 -fwasm-exceptions -sEXCEPTION_STACK_TRACES=1 -pthread -sMEMORY64=1 -sDEFAULT_LIBRARY_FUNCS_TO_INCLUDE=$getWasmTableEntry --js-library=D:/dev/vtk-07-09/installRelease/lib/vtkWebAssemblyRenderWindowInteractor.js --js-library=D:/dev/vtk-07-09/installRelease/lib/vtkEmscriptenTestUtilities.js --use-port=emdawnwebgpu -s FULL_ES3=1 -s MIN_WEBGL_VERSION=2 -s MAX_WEBGL_VERSION=2 @CMakeFiles\main.rsp -o D:\dev\vtk-07-09\Examples\docs\public\demo\cpp-app-1\main.js && cd ."
em++: warning: -pthread + ALLOW_MEMORY_GROWTH may run non-wasm code slowly, see https://github.com/WebAssembly/design/issues/1271 [-Wpthreads-mem-growth]
error: handleI64Signatures: signature too long for emwgpuWaitAny
Error: Aborting compilation due to previous errors
em++: error: ''C:\Users\User\AppData\Local\fnm_multishells\28136_1752129150499\node.EXE' 'D:\dev\vtk-07-09\emsdk\upstream\emscripten\tools\compiler.mjs' -' failed (returned 1)
ninja: build stopped: subcommand failed.
6

This does not look to be the Cone example. Did you modify it? Are you finding VTK with find_package(VTK) or component-based find_package(VTK COMPONENTS ...)? It seems to be linking with the RenderingWebGPU module. It fails because webgpu needs -sJSPI=1 and you do not have that link flag.

7

Where should that usage requirement be added?

8

As of today, it should be added by consumers. In the future, RenderingWebGPU will have it in INTERFACE. RenderingWebGPU does not include that flag right now because JSPI is not standardized yet. That give users freedom to choose legacy -sASYNCIFY=1 in order to support browsers that do not have JSPI (like Safari and non-nightly firefox)

1 Like