Skip to content

Node.js > 16 fails on Windows#270

Open
cclauss wants to merge 2 commits intonode-ffi-napi:masterfrom
cclauss:patch-1
Open

Node.js > 16 fails on Windows#270
cclauss wants to merge 2 commits intonode-ffi-napi:masterfrom
cclauss:patch-1

Conversation

@cclauss
Copy link
Copy Markdown

@cclauss cclauss commented Mar 29, 2024

Test results: https://github.com/cclauss/node-ffi-napi/actions

Recommendations:

  • Do not run npm test
  • macOS and Ubuntu: Node.js v20.x and Python 3.12
  • Windows: Node.js v16.x and Python 3.11 -- Do not run node-gyp rebuild

Lessons learned:

  1. Node.js >= v21 fails
  2. Node.js >= 18 fails on Windows
  3. Python >= 3.12 fails on Node.js 16 because of distlib fixed in node-gyp v10.0
  4. npm test fails with npm ERR! Missing script: "test"
  5. node-gyp rebuild fails on Node.js 16

Recommendations:
* Do not run `npm test`
* macOS and Ubuntu: Node.js v20.x and Python 3.12
* Windows: Node.js v16.x and Python 3.11 -- Do not run `node-gyp rebuild`

Lessons learned:
1. Node.js >= v21 fails
2. Node.js >= 18 fails on Windows
3. Python >= 3.12 fails on Node.js 16 because of distlib fixed in node-gyp v10.0
4. `npm test` fails with: npm ERR! Missing script: "test"
5. `node-gyp rebuild` fails on Node.js 16
@cclauss cclauss changed the title Node.js > 16 failes on Windows Node.js > 16 fails on Windows Mar 29, 2024
@btsimonh
Copy link
Copy Markdown

try
"node-gyp-build": "^4.2.1", -> "node-gyp-build": "^4.8.2",
A security patch in nodejs messed with all late nodejs versions and node-gyp:

nodejs/node#52554

and referenced nodejs patch:

https://nodejs.org/en/blog/vulnerability/april-2024-security-releases-2

Basically, any spawn of .cmd or .bat needs the shell:true option.

@cclauss
Copy link
Copy Markdown
Author

cclauss commented Oct 23, 2024

"node-gyp-build": "^4.2.1",

@btsimonh Unfortunately the AppVeyor Windows tests continue to fail on Node.js > v16.

@btsimonh
Copy link
Copy Markdown

ok, remove the .lock file - should it be comitted?
Also, I changed:
image
(I found this on some other repo).
image
(got this from you?)
and
image
(i don't know if prebuildify made a difference).

There was a change to a .h, but maybe I lost it and it was not important, maybe a warning only.

@btsimonh
Copy link
Copy Markdown

btsimonh commented Oct 23, 2024

With the above changes,, on windows, using node 22, tests work for node-ffi-napi, node-ref-napi, and ref-struct-ci, and they all then work together in my windows-root-certs once modified (which uses ref-struct and node-ffi to read a complex windows API from Cyrpto32.dll). I was giving up hope, but does not seem too bad :).

out of interest, does appveyer test on OSX and linux? - I'll need the 'set' to work on all :( but my OSX machine is probably too old to build on now.

@amolinarius
Copy link
Copy Markdown

Any updates on this?
I would really like to see this PR merged because i have the same problem on Win11 with node 22.12.0 (stable)

@cclauss
Copy link
Copy Markdown
Author

cclauss commented Dec 28, 2024

Did you try the alternatives mentioned in

@amolinarius
Copy link
Copy Markdown

i did not, just switched to Node 16 using nvm. I couldn't change module to use another as advised in this issue, because i had this problem with Vosk, that has this in the dependencies and not ffi-napi itself
Thanks anyway and happy new year ^^

urbanogilson added a commit to napi-ffi/node-ffi-napi that referenced this pull request Apr 4, 2026
* Bump version to 4.0.5

Upstream fixes present:
- libffi.gyp: correct preprocess_asm.cmd path for Windows (node-ffi-napi#293, node-ffi-napi#265)
- src/ffi.cc: remove NAPI_EXPERIMENTAL define (node-ffi-napi#283)
- node-gyp-build bumped to ^4.8.2, prebuildify to ^6.0.1 (node-ffi-napi#283)
- Supported on node 22 (Linux/Mac/Windows/Mingw) node-ffi-napi#281 node-ffi-napi#270


* Add MinGW (MSYS2 MINGW64) build and test job

Uses MSYS2's own Node.js package so os.type() returns MINGW64_NT-*,
which activates the MinGW code path in libffi.gyp (GCC compiles .S
files directly instead of the MSVC preprocess_asm.cmd route).

* Improve MSYS2 detection

* Use MSYSTEM_PREFIX to detect MSYS2 toolchain instead of MSYSTEM

* Skip uv_fs_open symbol check on MinGW/MSYS2 Windows builds

On MSYS2 MinGW nodes, libuv is not necessarily re-exported from the
node binary, so GetProcAddress("uv_fs_open") returns error 127. The
test still verifies that Library(null, {}) succeeds on MinGW; only the
MSVC-specific symbol export assumption is skipped.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants