npm install fails as node-gyp is unable to build lmdb #8152
Comments
|
+1 |
|
Cannot install the new parcel on two machines with Win10, tried with Node 14.16.0, 14.16.1 and 16.15.0. On one machine npm says it cannot find Python. On the other one it says it cannot find MSVS, and all because of node-gyp and lmdb. I hope 2.5.0 is not the last version to work on both of my computers. Cause it would be really uncomfortable to install Python, install MSVS and all the necessary build tools for Parcel which used to work like a charm just several days ago, and the main advantage of Parcel is that it's supposed to work just out of the box! |
|
Here's what I have: |
|
Okay, I resolved my issue. But this is still lame. |
|
cc @kriszyp |
|
The I would check to make sure your binaries have been properly installed by NPM first. @rincewindcz, your binary should be at If the binary is there, the next thing I would try is to force the npm install to not using any locally compilation by using One other thing to check is to make sure that there was no weird package version override and that the correct versions are with Hopefully that helps isolate the issue, certainly let me know if you have any questions. |
|
NPM will rollback failed installation, so
#!/bin/sh
basedir=$(dirname "$(echo "$0" | sed -e 's,\\,/,g')")
case `uname` in
*CYGWIN*|*MINGW*|*MSYS*) basedir=`cygpath -w "$basedir"`;;
esac
if [ -x "$basedir/node" ]; then
exec "$basedir/node" "$basedir/../node-gyp-build/build-test.js" "$@"
else
exec node "$basedir/../node-gyp-build/build-test.js" "$@"
firun Notice the stacktrace is from PS. so funny that it only recognizes |
|
Hmm, this is an interesting and helpful observation @yume-chan . And indeed, when I run So IIUC, the possibility that you are suggesting is that on some computer/configuration these paths are not being passed correctly by npm, and it is causing the wrong And if that is the case (and the users above do actually have the correct native binaries), the issue is about fixing the check for the prebuilt binaries to ensure no mixups in the test script. And I believe I could update |
I think it just resolves to local
My
Yes, with |
|
Ok, I published an updated |
|
Thanks to everyone who has put work in on this already, especially Kris for publishing that update. Unfortunately, I'm still getting this error.
"resolutions": {
"node-gyp-build-optional-packages": "4.3.4"
}to my Edit: I should note that |
|
Ok, trying again with 4.3.5, hopefully the carriage returns are gone now. |
|
4.3.5 is working for me. |
|
@kriszyp The good news is, your update of Thanks a lot! |
|
Great to hear, thank you @yume-chan for actually figuring out the issue! |
|
Just chiming in to say that 4.3.5 fixed it for me, too. Thanks so much! |
|
Yes, I can confirm that now it's working too. Thanks to everybody involved! |
|
Yes, I can confirm that it works now too. Thanks, very helpful |
|
Hey @kriszyp , 4.3.5 doesn't seem to work for me. On running this command:
Facing the below error: > [email protected] install /home/srishilesh/GitHub/Gatsby/node_modules/msgpackr-extract
> node-gyp-build-optional-packages
make: Entering directory '/home/srishilesh/GitHub/Gatsby/node_modules/msgpackr-extract/build'
CXX(target) Release/obj.target/extract/src/extract.o
../src/extract.cpp: In member function ‘napi_value__* Extractor::extractStrings(napi_env, int, int, uint8_t*)’:
../src/extract.cpp:165:121: error: no matching function for call to ‘v8::Array::New(v8::Isolate*, v8::Local<v8::Value>*, int&)’
165 | v8::Local<v8::Array> v8Array = v8::Array::New(v8::Isolate::GetCurrent(), (v8::Local<v8::Value>*) target, writePosition);
| ^
In file included from ../src/extract.cpp:10:
/usr/include/nodejs/deps/v8/include/v8.h:3674:23: note: candidate: ‘static v8::Local<v8::Array> v8::Array::New(v8::Isolate*, int)’
3674 | static Local<Array> New(Isolate* isolate, int length = 0);
| ^~~
/usr/include/nodejs/deps/v8/include/v8.h:3674:23: note: candidate expects 2 arguments, 3 provided
../src/extract.cpp:166:3: error: ‘memcpy’ was not declared in this scope
166 | memcpy(&array, &v8Array, sizeof(array));
| ^~~~~~
../src/extract.cpp:11:1: note: ‘memcpy’ is defined in header ‘<cstring>’; did you forget to ‘#include <cstring>’?
10 | #include <v8.h>
+++ |+#include <cstring>
11 | #endif
make: *** [extract.target.mk:119: Release/obj.target/extract/src/extract.o] Error 1
make: Leaving directory '/home/srishilesh/GitHub/Gatsby/node_modules/msgpackr-extract/build'
gyp ERR! build error
gyp ERR! stack Error: `make` failed with exit code: 2
gyp ERR! stack at ChildProcess.onExit (/usr/share/nodejs/node-gyp/lib/build.js:194:23)
gyp ERR! stack at ChildProcess.emit (events.js:198:13)
gyp ERR! stack at Process.ChildProcess._handle.onexit (internal/child_process.js:248:12)
gyp ERR! System Linux 5.13.0-52-generic
gyp ERR! command "/usr/bin/node" "/usr/bin/node-gyp" "rebuild"
gyp ERR! cwd /home/srishilesh/GitHub/Gatsby/node_modules/msgpackr-extract
gyp ERR! node -v v10.19.0
gyp ERR! node-gyp -v v6.1.0
gyp ERR! not ok Could you please help me figure out the issue? Thanks. |
|
@srishilesh msgpackr-extract is not a (required) dependency of gatsby. Or parcel. Or lmdb-js. Or msgpackr. So if you have not explicitly added msgpackr-extract as a dependency in your package.json, this should just be logging noise, not a real failure. Also, this is because node.js v10 is not a supported version of node (according to node.js themselves, and generally unsafe to use due to a lack of security patches). |
|
I think this is broken again on the latest version of Parcel because 2.6.1 upgraded lmdb which in turn requires |
Thanks for the help. Noted. |
|
@JavaScriptBach Is this alpine or standard linux? I haven't been able to reproduce this. Do you have a package.json (or lock) that might reproduce this? |
Standard linux; I've created a repo with instructions here: https://github.com/JavaScriptBach/test-parcel-gyp The issue seems to only appear when we run |
@JavaScriptBach Ah, I see. Yes, lmdb-js (as well as parcel-css and probably others) include the prebuilt binaries as optional packages, as this allows npm (or yarn, etc.) to exclude prebuilt binary packages that don't match the current architecture, without error. And the prebuilt binaries are technically "optional"; they aren't a hard requirement since you can build the binaries locally from source, as long as you have build tools/python installed. However, since you don't seem to have python installed, I assume you do want the prebuilt binaries, and therefore need to remove the |
|
I resolved my issue by |
I tried this and got the error |
|
@lmdb/lmdb-darwin-x64 is the corresponding binary file for Mac with Intel. |
|
For me this whole |
|
got the same error after upgrading Node to v18 |
|
Yet another +1 that downgrading to node v16 (from v19 for me) was a successful (temporary?) fix for me. |
|
I had this issue after copying all my repositories from an Intel MacBook to a M2 MacBook. This is what helped me instantly.
|
|
I had this issue on M1 MacBook Pro. |
|
Our GitHub action workflow (https://github.com/sillsdev/TheCombine/blob/parcel-babel-jest/.github/workflows/frontend.yml) has started hitting this gyp error. In one job, the error is fixed by adding Error before changing Adding Error with Error with Here's the |
|
As suggested here in another issue, I resolved this issue with |
🐛 bug report
When trying to install parcel into npm project,
npm install --save-dev parcelfails with exit code 7, complaining about node-gyp failing to buildlmdbpackage.🎛 Log
🌍 Your Environment
The text was updated successfully, but these errors were encountered: