I'm pretty new to node.js and its package management system and its require. I'm having trouble with the following runtime error I'm getting after having installed a bunch of packages with npm install:
ERROR: Couldn't initialise framework "wdio-mocha-framework".
Error: /usr/lib/libstdc++.so.6: version `GLIBCXX_3.4.9' not found
(required by <path>.../node_modules/fibers/bin/linux-ia32-v8-5.0/fibers.node)
at Error (native)
My understanding of the error is that the binary fibers.node was compiled with a newer libstdc++ than the one available at runtime.
It appears to me like the npm install did compile a fibers.node:
> fibers#1.0.13 install <path>.../node_modules/fibers
> node build.js || nodejs build.js
make[1]: Entering directory `<path>.../node_modules/fibers/build'
<snip some output, including warnings, here that I don't deem relevant>
Installed in `<path>.../node_modules/fibers/bin/linux-ia32-v8-3.14/fibers.node`
However, I see that the fibers.node that is throwing the error at runtime is not the same one as was compiled, and I assume that's the source of the problem.
Compiled:
.../linux-ia32-v8-3.14/fibers.node
Used at runtime and fails:
.../linux-ia32-v8-5.0/fibers.node
So I'm guessing and hoping that if I could convince wdio-mocha-framework to use the locally-compiled fibers.node, it would work. My questions are thus:
Would that fix it?
If so, how do I achieve that?
If not, what's the correct direction to take to further understand and fix this error? Perhaps instead of getting 3.14 to be used at runtime, I should be convincing 5.0 to be compiled at install-time? Or ... other?
Your help is most sincerely appreciated.
Update/Edit:
I think I solved this on my own, in case anyone ever finds this poor, dusty old question lying forgotten on the back of a shelf somewhere...
The problem was apparently due to multiple versions of node/node-gyp that were installed in my environment in parallel, and the build process, even though it was started with a newer version of node, was finding node-gyp in the $PATH and that's apparently what caused the old version of fibers to be built. At least, I think so.
Just had this problem recently. I managed to solve it just by uninstalling the current version of Node.JS (I had the most recent, in this case 9.5.0) and installing the recommended, in this case 8.9.4. and the issue is gone. hope this helps someone.
Related
System information
OS Platform and Distribution (e.g., Linux Ubuntu 16.04): macOS Ventura 13.2.1
TensorFlow.js installed from (npm or script link): npm
TensorFlow.js version: 4.2.0
Describe the problem
I had previously used the #tensorflow/tfjs-node library successfully with no issues. Now, however, I have changed environments and unfortunately I am running into issues. I don't have the original source code any more to compare to see what the difference is.
I am running under node v18.4.0, although I have tried v16.16.0 and v14.21.2 (using nvm on macOS).
The problem is now it seems the library wants all sorts of supporting modules, which are not installed:
aws-sdk
nock
mock-aws-s3
It will not build without these, so I npm i them and then it builds happily.
So first question: why might my environment now be needing these where it didn't need them before? What might be different? As I say, sadly I don't have the last environment around any more.
Having built this, I now receive the error:
Error: #package/learn package.json is not node-pre-gyp ready:
package.json must declare these properties:
binary
Although I could configure all this, I think it is the wrong thing to do, since I had it up and running previously without any of this. Is where are these issues now coming from?
Can I run the #tensorflow/tfjs-node without installing or needing those three dependencies? I can provide the other config if it is not apparent to someone who has had the same issue.
Had my node working with the VS Code debugger last night no problem. I haven't touched anything besides install the npm mysql package.
I come back tonight and its throwing this error:
Debugger listening on [::]:49952
dyld: lazy symbol binding failed: Symbol not found: _napi_module_register
Referenced from: /Users/adamsawyers/node_modules/bufferutil/prebuilds/darwin-
x64/node-napi.node
Expected in: flat namespace
dyld: Symbol not found: _napi_module_register
Referenced from: /Users/myusername/node_modules/bufferutil/prebuilds/darwin-
x64/node-napi.node
Expected in: flat namespace
Apparently my installation of n (a node version handling package in npm) is busted somehow. My research told me that napi_module_register is part of the n package, but I'm not sure how this got messed up especially since I had it working last night.
I tried reinstalling my node packages, reinstalling n, rebuilding the project file structure, even restarting my computer. Nothing has worked so far.
Any suggestions?
Apparently VS code doesn't like v6.10.3 of nodejs which I am running to create lambda functions in AWS (that is the version specified by AWS)
I use the N package to manage my node version. After switching to the latest version 10.7.0 as of 07/25/2018 (command: sudo n latest) and rerunning the debugger in VS code, it worked perfectly
I'm still unsure as the the cause, but hopefully others find this solution helpful
This exact error happened to me because:
I needed socket.io to run on Node
Which in turn needs ws (websockets on Node)
Also, I needed to run this on an outdated Node version (Node 7) for a very good reason (believe me, I would not want to do this if I wouldn't have to)
However, trying to use it on that old version causes above error message.
Solution
This is a terrible solution, but at least I got it to work.
After some researching, I found no good solution to this. However, a close look at the source code shows that there is a fallback.js next to index.js which implements the same functionality as the native build but without needing a build. This will probably slow things down significantly, but at least it works:
yarn add module-alias
prefix your actual code with this (e.g. via node -r fallbacks.js):
// fallbacks.js
const moduleAlias = require('module-alias');
const dependencyRoot = getDependencyRoot(); // whatever is your root folder, maybe __dirname + '..'
moduleAlias.addAlias('bufferutil', dependencyRoot + '/node_modules/bufferutil/fallback.js');
moduleAlias.addAlias('utf-8-validate', dependencyRoot + '/node_modules/utf-8-validate/fallback.js');
// run actual code here...
PS: In my case, in order to allow ws to run on Node 7, I also had to babel it, since its using modern synytax.
I was using node v0.12, and just wanted to update my npm packages, however, the new version of node uses node-sass and libsass as a compiler.
I am using grunt-sass to compile my files, but ended up with a lot of errors that occur only with Libsass.
Here is an example that seems happen on sassmeister.com when using the Libsass compiler.
The solution is to add a space after the :, fine, but this is not the solution am seeking, any help please?
Here is a gist to experiment the issue and it has a weird fix tho.
http://www.sassmeister.com/gist/b8197cf0593d722f808809e8979f2ab9
I've seen similar questions but no real solution that worked for me yet (most users just reinstall fibers or meteor (I'm not using meteor)).
I've added the nodejs module Sync to my nodejs 0.12.6 project. It's dependency is the Fibers module that got installed automatically with Sync. Now I wanted to load Sync via require, but it fails with the message
... /win32-x64-v8-4.3/fibers.node not found
And it's correct: In sync/node_modules/fibers/bin/ is no directory named win32-x64-v8-4.3, only win32-x64-v8-4.2 and renaming didn't solve the problem (would have been too easy)... 🙈
How can I solve this problem? How can this happen?
What is the meaning of the last number (4.3)? I guess it's windows, 64bit, Javascript v8 engine, and then? Fibers version?
Any ideas or hints?
Update:
I tried to updgrade node to 0.12.6, but nothing changed.
I found out what the 4.3 is about, it's the v8 version. Well, when running my application with electron, it is v8: '4.3.61.21'. When checking the version with node, it is 3.28. So it's maybe electrons "fault"?
Update #2:
Okay i found out that electron is based on io.js and not node. That explains the different v8 versions. But still no solution. When installing fibers with latest io.js (2.3.3), it tests the 4.2 binary, but electron requires 4.3 :(
Update #3:
Even with the same io.js version 2.3.1 as electron, it does only install the 4.2 binary.
Update #4:
Now, I've tried all three ways described at http://electron.atom.io/docs/v0.27.0/tutorial/using-native-node-modules/ (with electron version 0.29.1) - still no solution. There aren't any binaries for v8-4.3, still only the v8-4.2 ones. :(
Solution:
See my answer below. :)
At the end, i had to compile fibers on my own. As described in Update #4, i've tried it before. But node-gyp always failed and i didn't notice that i have to link to the new binary file on my own...
cd ~/my-project-root/
npm install sync
cd ./node_modules/sync/node_modules/fibers
node-gyp configure
HOME=~/.electron-gyp node-gyp rebuild --target=0.29.1 --arch=x64 --dist-url=https://atom.io/download/atom-shell
Then i've created the missing directory and moved the new binary there:
mkdir bin/win32-x64-v8-4.3
mv build/Release/fibers.node bin/win32-x64-v8-4.3/fibers.node
Now Sync works like a charm.
You need to use the electron-rebuild tool to rebuild your native module against the version of Electron you're using
I get invalid packages installing, even if the installation is a success. Btw, this question is related to the answer - question about versioning
npm install serialport
These are packages which is stuck far in the dependency tree.
npm ERR! invalid: readable-stream#1.0.27-1 /Users/snorre edwin/Code/raspberry-node-server/node_modules/serialport/node_modules/node-pre-gyp/node_modules/tar-pack/node_modules/readable-stream
npm ERR! invalid: string_decoder#0.10.25-1 /Users/snorre edwin/Code/raspberry-node-server/node_modules/serialport/node_modules/node-pre-gyp/node_modules/tar-pack/node_modules/readable-stream/node_modules/string_decoder
This ends up causing this error in my browser:
Uncaught TypeError: Cannot read property '_ansicursor' of undefined
Is there any way to sort up in this npm problem? Can I avoid these prerelease packages?
The github answere below gave me a lot of insight into npm and I thought I had to dig somewhere else for the issue. But it acctually just seemed like serialport does not work very well, anymore, with browserify. It used to work because i used if for two months, but something changed. When im saying it out loud, it just sounds stupid anyway. So dont browserify serialport.
I recieved an answere on github, issue answere, thought i would share it with the rest who might wonder:
The change in handling prerelease versions in semver#4 is one of the primary motivators for the major version bump to npm#2. All versions of npm 2 are affected by this change, which, put briefly, ensures that all version information to the right of - in version strings is ignored when doing semver range matching. When you upgrade from npm#1 to npm#2, it's normal to see some irregularities show up when you run npm -g ls, and since some packages are distributed as self-contained installs via the use of bundledDependencies, they may come out of the package in a state that is inconsistent with npm#2's rules.
While this won't always work, most of the time the easiest way to fix these issues is simply to uninstall and reinstall the affected package. For packages that ship with bundledDependencies, if you really want to get everything cleaned up, you can cd into the node_modules folder containing the version of the package with the noisy prerelease dependency version and just run npm install problemDependency, and it will use the newest version of that dependency that matches the semver range for that particular package.
Re: your second question, semver range checking is done semantically, not lexically, so 1.0.31 should match with npm#2:
% semver -r '~1.0.2' 1.0.26 1.0.27-1 1.0.31
1.0.26
1.0.31
I suspect that the behavior you're seeing is due to a bundledDependency included in the package tarball.
All of this is documented, so I'm going to close this issue. I hope this clears things up for you!