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
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.
Some packages that depend on https://www.npmjs.com/package/fibers fail to install with error message above. Particularly it is iron-meteor.
Homepage of the fibers states:
meteor users please read this
If you're trying to get meteor running and you ended up at this page you're probably doing something wrong. Please uninstall all versions of NodeJS and Meteor, then start over. See meteor#5124 for more information."
But it does not seem to be very helpful.
One guy recommends to downgrade node.js here https://github.com/NativeScript/NativeScript/issues/2991
It helps indeed, but it is kind of hack, right?
Node version affected: v7.2.0
Node v6.9.2 works well.
WeakCallbackData was removed from the V8 API earlier this year. Since this change has landed in Node 7, packages that rely on v8::WeakCallbackData don't work anymore. You need to downgrade Node or wait until Meteor supports Node 7, i.e., uses a newer node-fibers version.
I have written a Electron application using Node, Electron Boilerplate, and phantom. It works perfectly fine for me on my linux machine, I copied the source over to Windows 10, and ran with npm start, and all goes smoothly.
However, when I try to build the application with the boilerplate module using npm run release, things go a little less smoothly. I can install and open the application just fine, but when I click the button that activates the phantom module, the windows goes all white and nothing happens. I was able to logs some errors with the dev tools.
First, I have:
C:\...\dist\win-unpacked\resources\app.asar\node_modules\phantom\lib\phantom.js:361
Uncaught (in promise) Error: Error reading from stdin: Error: write EPIPE(…)
I did some research into similar issues, namely here, and it seems to me the issue is starting the child process, PhantomJS, with the npm module phantom. Originally, I was using a WPF application I wrote in C# to start the process, and that worked just fine. This leads me to believe that the phantom module is the culprit.
So I tried swapping out the npm phantom module for horseman, but got similar results:
Unhandled rejection HeadlessError: Phantom immediately exited with: 4294967295
at ChildProcess.immediateExit (C:\...\dist\win-unpacked\resources\app.asar\node_modules\node-horseman\node_modules\node-phantom-simple\node-phantom-simple.js:153:23)
at ChildProcess.g (events.js:286:16)
at emitTwo (events.js:106:13)
at ChildProcess.emit (events.js:191:7)
at Process.ChildProcess._handle.onexit (internal/child_process.js:204:12)
Here is a shot in the dark. I am not positive this will solve your issue but here it goes:
GYP and miss-matched binaries
Phantom and many other node modules use binaries built for the specific OS that it will be running on. Sometimes in your npm log files you will see references to node-gyp. Node-gyp simply helps to build native add-on's in node modules. When the binaries are built they are usually built against, among others, three main parameters, the operating system, cpu architecture and version of node that is doing the installation.
I think you need to rebuild phantomjs to the version of node Electron is using. Most of the time the node version you have installed on your machine and the node version running in Electron are not the same. Electron does its best to keep up, but there is always a little lag because of the amount of work and testing required to keep up-to-date.
When you install phantom by running npm install phantom it will assume it needs to install or build the binaries for the node version your machine is using. Then when your Electron app tries to run phantom it tries to call the binary of the Electron's node version. When it isn't there the child process immediately exits with an error.
How to fix
Luckily, there are other people out there that have figured out how to fix this issue and have created a great tool to help generate the correct binaries.
Enter electron-rebuild:
https://github.com/electron/electron-rebuild
Electron-rebuild can be run in the command line, and it will rebuild all of your native modules to the version of Electron your project is using.
To install:
npm install electron-prebuilt
To use (in Windows):
.\node_modules\.bin\electron-rebuild.cmd
This should be enough to put the correct binaries in the right place.
Other thoughts
Sometimes you can use a package that uses a dependency called node-pre-gyp. E.g. sqlite3. There is a known issue I ended up running into when trying to rebuild my packages for Electron. Basically, in order to avoid this issue (if you run into it) just append --pre-gyp-fix to the above command.
Tangent for those who run into the pre-gyp-fix issue
One more thing on the pre-gyp-fix: If one or more of your dependencies depends on one of the modules that need the pre-gyp-fix then they will be looking for the binary in the wrong place even if they are running in Electron. All of the pre-gyp binaries are stored in a folder similar to this:
.\node_modules\sqlite3\lib\binding
In my current project I have three folders here, one for Electron-v1.4, and two for node-v46 and node-v50. (hack alert) In order to have sqlite3 work with my other dependencies I copy the binary found in the Electron-v1.4 folder and put it in both node-v* folders. That way when running in Electron, all dependencies are running the correct binaries even though they are looking for them in the wrong place. (end hack alert)
Conclusion
There is no way I can be sure this has anything to do with the issue you are seeing. But it is worth a shot to see if it fixes your problem. If not then at least I hope I can help someone else experiencing the same issues I ran into.
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.
I'm new to Electron, and I really love it so far, but I'm unable to package any of mine apps, at first I thought that it's maybe something related to my code, then I download "https://github.com/atom/electron-quick-start" run npm install and then I run "electron-packager . FooBar --platform=darwin --arch=x64 --version=0.28.2" it build the app but when I try to open it I get
so I didn't touch any code from the example, just wanted to build it and I got an error, what am I doing wrong? Thanks!
The versions of electron are moving very very fast.
And some times, they don't respect the "old" ways to do things (for example, declaring the app).
I advise you to not use the 0.28.2 version of electron but the most recent one.
It is very likely that the version of electron-prebuilt you are using to develop is much much much more recent than the 0.28.2 version. So, you are developing with something much newer, and then you are building with 0.28.2. This would cause the exact error that you are seeing, as older versions may not have had the electron module, which your code explicitly is importing. So... that is my suggestion. Change the version in your electron-packager command from 0.28.2 to something like 0.36.0. See if that works. Or better yet, use the same version as electron-prebuilt in your package.json.
This could be a combination of factors.
First, as others stated, the version of electron that you have might be newer than the one referenced in your build command. Locate the 'electron_prebuilt' folder inside your 'node_modules' folder, and examine the package.json file and make sure the version # is the same as what you are declaring in your build command.
If they are the same, then the issue might be that you have another version of electron on your computer that node is trying to use. If you installed electron via the -g option (global), check your home folder to see if there is another different version of electron. If you find one, either delete it or rename the 'electron_prebuilt' folder you find to something else. Try your build command again, and it should work now that you've eliminated the other versions of electron_prebuilt on your computer that node was referencing.
What worked for me was to move the "electron" module from "dev-dependencies" to "dependencies" in package.json. Try this and see if it works.