Adding Support for Win32 ARM64

[alan-agius4]

Currently, this library does not support the Win32 ARM64 platform, resulting in the following error during runtime:

No native build was found for platform=win32 arch=arm64 runtime=node abi=127 uv=1 armv=8 libc=glibc node=22.3.0
    attempted loading from: D:\Junk\my-app\node_modules\lmdb and package: @lmdb/lmdb-win32-arm64

[kriszyp]

Are you aware of any Node.js native packages that have managed to do Windows ARM builds yet? I haven't found any, and I believe that this actually requires a Windows ARM runner to do the compilation, which is not currently not available anywhere, AFAIK:
parcel-bundler/lightningcss#724
lovell/sharp#2553
TryGhost/node-sqlite3#874

[alan-agius4]

Esbuild and rollup seem to support ARM64

• https://unpkg.com/browse/[email protected]/package.json (@rollup/rollup-win32-arm64-msvc)
• https://unpkg.com/browse/[email protected]/package.json (@esbuild/win32-arm64)

[richardmynameis]

Hi @alan-agius4 did you find a way how to solve this error ?
I think many more people who develop on mac in parallels will have same issue.

For now i was able to solve it with downgrade of node version from v20 to v18.

My error was :
No native build was found for platform=win32 arch=arm64 runtime=node abi=115 uv=1 armv=8 libc=glibc node=20.12.2

[kriszyp]

It looks like rollup is using rust/cargo to do the builds, and I don't even see where esbuild builds are performed. I am not sure how these would inform how to run node-gyp build with an ARM target. I definitely would still love to do add support for Windows ARM if anyone finds anything that could help. PRs obviously welcome too.

[hakimio]

esbuild is using go to build win32-arm64:
Makefile
go source code

[kriszyp]

I don't really follow how the Makefile runs those source code files (not really a Go programmer, and seems like rewriting the lmdb-js build process would be a pretty big change and difficult to maintain, but again, PRs are welcome.)

[jbennie]

Hi this is a show stopper for developing angular aps on windows on ARM without resorting to wsl. (Snapdragon x1E84100 )

The problem however might be as simple as a path with a whitespace not being parsered.
See my error log below - specifically the section when trying to fallback to a native compile - I've check all the correct dependencies exist on my host. VS2022 with MVCS C++ ARM MVC/ALT Libs etc.

npm error path K:\github\cssproject\frontendtools\AP2020\ap-app\node_modules\lmdb
npm error command failed
npm error command C:\windows\system32\cmd.exe /d /s /c node-gyp-build-optional-packages
npm error K:\github\cssproject\frontendtools\AP2020\ap-app\node_modules\node-gyp-build-optional-packages\node-gyp-build.js:85
npm error throw new Error(errMessage)
npm error ^
npm error
npm error Error: No native build was found for platform=win32 arch=arm64 runtime=node abi=127 uv=1 armv=8 libc=glibc node=22.5.1
npm error attempted loading from: K:\github\cssproject\frontendtools\AP2020\ap-app\node_modules\lmdb and package: @lmdb/lmdb-win32-arm64
npm error Error resolving package: Cannot find module '@lmdb/lmdb-win32-arm64'
npm error Require stack:
npm error - K:\github\cssproject\frontendtools\AP2020\ap-app\node_modules\lmdb\package.json
npm error
npm error at load.resolve.load.path (K:\github\cssproject\frontendtools\AP2020\ap-app\node_modules\node-gyp-build-optional-packages\node-gyp-build.js:85:9)
npm error at load (K:\github\cssproject\frontendtools\AP2020\ap-app\node_modules\node-gyp-build-optional-packages\node-gyp-build.js:28:30)
npm error at Object. (K:\github\cssproject\frontendtools\AP2020\ap-app\node_modules\node-gyp-build-optional-packages\build-test.js:19:19)
npm error at Module._compile (node:internal/modules/cjs/loader:1504:14)
npm error at Module._extensions..js (node:internal/modules/cjs/loader:1588:10)
npm error at Module.load (node:internal/modules/cjs/loader:1282:32)
npm error at Module._load (node:internal/modules/cjs/loader:1098:12)
npm error at TracingChannel.traceSync (node:diagnostics_channel:315:14)
npm error at wrapModuleLoad (node:internal/modules/cjs/loader:215:24)
npm error at Function.executeUserEntryPoint [as runMain] (node:internal/modules/run_main:158:5)
npm error
npm error Node.js v22.5.1
npm error
npm error The failure above indicates the primary issue with the native builds which are included for all major platforms. Will now attempt to build the package locally in case this can be resolved by re-compiling.
npm error 'C:\Program' is not recognized as an internal or external command,
npm error operable program or batch file.

[sohcah]

As of yesterday, GitHub actions now has GA Support for Windows ARM64 runners - https://github.blog/changelog/2024-09-03-github-actions-arm64-linux-and-windows-runners-are-now-generally-available/

It looks like one of the examples mentioned above (parcel-bundler/lightningcss#724) does now have Windows ARM64 support, so I wonder if this might be possible now?

[miladfm]

any update?

[kriszyp]

any update?

Yes, we have been continuing to work hard on this. I believe the Windows ARM64 runners are only available with paid accounts (or has that changed), so working @HarperDB, to try get builds running. We have the process started, but the current problem seems to be that Visual Studio is missing on Windows ARM64 runners, which is critical for the builds:
https://github.com/HarperDB/lmdb-js/actions/runs/11292316151/job/32695626446
Certainly open to ideas on how to resolve this. We would still really love to get Win ARM64 builds available as soon as possible, but this is the current roadblock.

[miladfm]

Thank you for the quick reply.

I also found a temporary fix to run the app. In my case, I’m using Angular, and by updating my pnpm config as shown below, I no longer receive errors. However, this approach isn’t native and increases build time. It’s a workaround until the current issue is resolved.

Here’s what I used:

"pnpm": {
  "overrides": {
    "@angular/build>lmdb": "-"
  }
},
"optionalDependencies": {
  "lmdb": "3.1.4"
}

Source: angular/angular-cli#27882 (comment)

[brunomantovani]

For this problem, I decided to use the x64 version of Node instead of ARM64 since this library does not support those platforms.