Fix build failure with node-gyp@^10.0.0#265
Fix build failure with node-gyp@^10.0.0#265Weather-OS wants to merge 1 commit intonode-ffi-napi:masterfrom
Conversation
|
I've forked/applied fixes to both ref-napi & ffi-napi here: https://github.com/avvs/ref-napi It's auto published right now with semantic-release, though, admittedly, lacks some prebuilt binaries the original had. You could install packages via I've tried taking a stab at also upgrading bundled libffi, but that requires a bunch of os/arch combos I dont have access to. Might try doing something with docker bake where headers are generated appropriately in containers @addaleax @indutny not sure if you have any time to work on updating this at all, I did what I could mainly to address the memory bloat, will have a few days over the upcoming holidays to try and merge everything to the mainstream distribution lmk if there is any interest in this and I'd be happy to dedicate a few days to port changes |
It works , thanks |
RaistlinTAO
left a comment
There was a problem hiding this comment.
This is a quick-fix bandage to solve the problem.
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)
* 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.
This fixes build failures relating to
'"call"' is not recognized as an internal or external commandon Windows.