Atom on Raspbian? - atom-editor

Very nooby question, but I'm trying to install Atom text editor on Raspbian Stretch. Is it possible? I've heard because it runs on Electron, it's quite slow for Raspbian. I keep getting an error saying:
E: Unable to locate package atom
I'm following the official instructions for Debian. How can I fix this?

As of today you can't install the official package provided for Debian for its mismatching the hardware platform. Provided binary is for running on x86 hardware, but RPi doesn't come with an Intel/AMD processor, but ARM. So, you most probably need to build it from source yourself.
Primer
So, if you really want to build this from source, you should be aware of the waste of disk space caused by the IMHO poorly implemented build tool which is downloading tons of deps and copying and transpiling code around so you'll end up with 2GB+ of files with 80% accounting to dependencies, only. Since my RPi works with 8GB smartcard, only, I couldn't ever meet the need for disk space even though I was bleeding out Linux by manually removing docs, manpages, locales, ton's of outdated and mostly unused apps etc. The build also requires a whole build tooling chain, tons of dev packages for libraries, so there is a limit to milk the system ... 8GB disk drive simply isn't enough for this.
Eventually I tried moving all the files to a USB pen drive. But that drive must be formatted using a filesystem capable of symlinking. So you can't use vfat or FAT32. I didn't succeed to get a 16GB stick formatted with either version of extfs. The mkfs always ended up in a deadlock on trying to write its superblocks. Astonishingly, I couldn't even kill the mkfs with -KILL, but unplugging the drive did help in that case.
So, as a conclusion: here is a short list of steps I passed in expectation to get this working, but in the end I didn't finish due to the memory issues above. And frankly, I stopped caring ... I'd rather work with nano/vi in a terminal than using this ridiculous lego-like built software. I guess, atom is today's version of emacs with regards to the latter's acronym. Maybe you succeed with this, but I won't ...
Build from Source
Inspired by https://discuss.atom.io/t/atom-on-the-raspberry-pi/33332
Install toolchain for building native stuff
sudo apt-get install build-essential git libgnome-keyring-dev fakeroot gconf2 gconf-service libgtk2.0-0 libudev1 libgcrypt20 python rpm libsecret-1-dev xorg-dev
This set of tools was sufficient to build core files without error. Since I didn't start with a fresh installation of Raspbian there might have been some tool I have been using before, so maybe in your case there are more tools to be installed here. Look out for error messages in early stage of building and try to see if some library or header file isn't found. This mostly indicates lack of some package with name ending in -dev to be installed, too. Start by searching for the package using apt search <name-of-mentioned-library> and look for a package combining the missing library's name with suffix -dev. Then install it the usual way by invoking sudo apt-get install <package-name>.
Install up-to-date nodejs
Raspbian Stretch comes with support for NodeJS 8.11 which is basically okay. Install it and its package manager npm using this command:
sudo apt-get install node-js npm
Check installed versions with
node -v
npm -v
This should display 8.x.x on behalf of NodeJs. Use n afterwards if you want to step up:
sudo npm i -g n
sudo n lts
This will switch NodeJS to latest LTS release, which is 10.x as of now. Upgrading NodeJS is optional, but feel advised to always use latest version of npm:
sudo npm i -g npm
Check if upgrades succeeded:
node -v
npm -v
Adjust configuration of npm and install some essential dep:
sudo npm config set -g python /usr/bin/python2
sudo npm i -g node-gyp
Build Atom
Get the source. One option is to pull latest code from its repository:
git clone https://github.com/atom/atom.git
This is creating subfolder atom containing all source files. You might want to download sources of a recent release instead. But this tutorial was made with the sources fetched from Github. So make sure there is subfolder called atom containing sources similar to the ones fetched above.
It's time to start the beast:
cd atom
./script/build
This process will take a while. And it is the culprit that never finished on success in my case due to eating up all disk space over and over again.
Whenever the script fails on error, try to analyze the error, find the cause, fix it, then start the script by repeating the last command above again. If you don't remove any file in subfolder atom in between, the build script keeps passing steps of building atom it has passed successfully before.
Install atom
According to the original tutorial linked before the script should finish on success eventually. Then it's time to install with:
./script/grunt install
I guess this is causing atom to be available as a command from CLI. So, try it out. If everything looks fine you are finally ready to remove the waste of files in subfolder atom.
Feel free to report if this was working in your case.

From what I recall Atom runs 64-bit architecture; need the latest raspberry Pi.

run the following
wget https://atom.io/download/deb && dpkg -i deb

Related

Qt Creator qt.qpa.plugin: Could not load the Qt platform plugin "xcb" on Ubuntu 20.04 [duplicate]

I wrote application for linux which uses Qt5.
But when I am trying to launch it on the linux without Qt SDK installed, the output in console is:
Failed to load platform plugin "xcb". Available platforms are:
How can I fix this? May be I need to copy some plugin file?
When I use ubuntu with Qt5 installed, but I rename Qt directory, the same problem occurs. So, it uses some file from Qt directory...
UPDATE:
when I create in the app dir "platforms" folder with the file libqxcb.so, the app still doesnot start, but the error message changes:
Failed to load platform plugin "xcb". Available platforms are:
xcb
How can this happen? How can platform plugin be available but can't be loaded?
Use ldd (man ldd) to show shared library dependencies. Running this on libqxcb.so
.../platforms$ ldd libqxcb.so
shows that xcb depends on libQt5DBus.so.5 in addition to libQt5Core.so.5 and libQt5Gui.so.5 (and many other system libs). Add libQt5DBus.so.5 to your collection of shared libs and you should be ready to move on.
As was posted earlier, you need to make sure you install the platform plugins when you deploy your application. Depending on how you want to deploy things, there are two methods to tell your application where the platform plugins (e.g. platforms/plugins/libqxcb.so) are at runtime which may work for you.
The first is to export the path to the directory through the QT_QPA_PLATFORM_PLUGIN_PATH variable.
QT_QPA_PLATFORM_PLUGIN_PATH=path/to/plugins ./my_qt_app
or
export QT_QPA_PLATFORM_PLUGIN_PATH=path/to/plugins
./my_qt_app
The other option, which I prefer is to create a qt.conf file in the same directory as your executable. The contents of which would be:
[Paths]
Plugins=/path/to/plugins
More information regarding this can be found here and at using qt.conf
I tried to start my binary, compiled with Qt 5.7, on Ubuntu 16.04 LTS where Qt 5.5 is preinstalled. It didn't work.
At first, I inspected the binary itself with ldd as was suggested here, and satisfied all "not found" dependencies. Then this notorious This application failed to start because it could not find or load the Qt platform plugin "xcb" error was thrown.
How to resolve this in Linux
Firstly you should create platforms directory where your binary is, because it is the place where Qt looks for XCB library. Copy libqxcb.so there. I wonder why authors of other answers didn't mention this.
Then you may want to run your binary with QT_DEBUG_PLUGINS=1 environment variable set to check which dependencies of libqxcb.so are not satisfied. (You may also use ldd for this as suggested in the accepted answer).
The command output may look like this:
me#xerus:/media/sf_Qt/Package$ LD_LIBRARY_PATH=. QT_DEBUG_PLUGINS=1 ./Binary
QFactoryLoader::QFactoryLoader() checking directory path "/media/sf_Qt/Package/platforms" ...
QFactoryLoader::QFactoryLoader() looking at "/media/sf_Qt/Package/platforms/libqxcb.so"
Found metadata in lib /media/sf_Qt/Package/platforms/libqxcb.so, metadata=
{
"IID": "org.qt-project.Qt.QPA.QPlatformIntegrationFactoryInterface.5.3",
"MetaData": {
"Keys": [
"xcb"
]
},
"className": "QXcbIntegrationPlugin",
"debug": false,
"version": 329472
}
Got keys from plugin meta data ("xcb")
loaded library "/media/sf_Qt/Package/platforms/libqxcb.so"
QLibraryPrivate::loadPlugin failed on "/media/sf_Qt/Package/platforms/libqxcb.so" : "Cannot load library /media/sf_Qt/Package/platforms/libqxcb.so: (/usr/lib/x86_64-linux-gnu/libQt5DBus.so.5: version `Qt_5' not found (required by ./libQt5XcbQpa.so.5))"
This application failed to start because it could not find or load the Qt platform plugin "xcb"
in "".
Available platform plugins are: xcb.
Reinstalling the application may fix this problem.
Aborted (core dumped)
Note the failing libQt5DBus.so.5 library. Copy it to your libraries path, in my case it was the same directory where my binary is (hence LD_LIBRARY_PATH=.). Repeat this process until all dependencies are satisfied.
P.S. thanks to the author of this answer for QT_DEBUG_PLUGINS=1.
I tried the main parts of each answer, to no avail. What finally fixed it for me was to export the following environment variables:
LD_LIBRARY_PATH=/usr/local/lib:~/Qt/5.9.1/gcc_64/lib
QT_QPA_PLATFORM_PLUGIN_PATH=~/Qt/5.9.1/gcc_64/plugins/
Ubuntu 16.04 64bit.
I got the problem for apparently no reasons. The night before I watched a movie on my VideoLan instance, that night I would like to watch another one with VideoLan. VLC just didn't want to run because of the error into the question.
I google a bit and I found the solution it solved my problem: from now on, VLC is runnable just like before. The solution is this comand:
sudo ln -sf /usr/lib/x86_64-linux-gnu/qt5/plugins/platforms/ /usr/bin/
I am not able to explain what are its consequencies, but I know it creates some missing symbolic link.
Since version 5, Qt uses a platform abstraction system (QPA) to abstract from the underlying platform.
The implementation for each platform is provided by plugins. For X11 it is the XCB plugin. See Qt for X11 requirements for more information about the dependencies.
There might be many causes to this problem. The key is to use
export QT_DEBUG_PLUGINS=1
before you run your Qt application. Then, inspect the output, which will point you to the direction of the error. In my case it was:
Cannot load library /opt/nao/plugins/platforms/libqxcb.so: (/opt/nao/bin/../lib/libz.so.1: version `ZLIB_1.2.9' not found (required by /usr/lib/x86_64-linux-gnu/libpng16.so.16))
But that is solved in different threads. See for instance https://stackoverflow.com/a/50097275/2408964.
Probably this information will help. I was on Ubuntu 18.04 and when I tried to install Krita, using the ppa method, I got this error:
This application failed to start because it could not find or load the Qt platform plugin "xcb" in "".
Available platform plugins are: linuxfb, minimal, minimalegl, offscreen, wayland-egl, wayland, xcb.
Reinstalling the application may fix this problem.
Aborted
I tried all the solutions that I found in this thread and other webs without any success.
Finally, I found a post where the author mention that is possible to activate the debugging tool of qt5 using this simple command:
export QT_DEBUG_PLUGINS=1
After adding this command I run again krita I got the same error, however this time I knew the cause of that error.
libxcb-xinerama.so.0: cannot open shared object file: No such file or directory.
This error prevents to the "xcb" to load properly. So, the solution will be install the `libxcb-xinerama.so.0" right? However, when I run the command:
sudo apt install libxcb-xinerama
The lib was already installed. Now what Teo? Well, then I used an old trick :) Yeah, that one --reinstall
sudo apt install --reinstall libxcb-xinerama
TLDR: This last command solved my problem.
I ran into a very similar problem with the same error message. First, debug some by turning on the Qt Debug printer with the command line command:
export QT_DEBUG_PLUGINS=1
and rerun the application. For me this revealed the following:
"Cannot load library /home/.../miniconda3/lib/python3.7/site-packages/PyQt5/Qt/plugins/platforms/libqxcb.so: (libxkbcommon-x11.so.0: cannot open shared object file: No such file or directory)"
"Cannot load library /home/.../miniconda3/lib/python3.7/site-packages/PyQt5/Qt/plugins/platforms/libqxcb.so: (libxkbcommon-x11.so.0: cannot open shared object file: No such file or directory)"
Indeed, I was missing libxkbcommon-x11.so.0 and libxkbcommon-x11.so.0. Next, check your architecture using dpkg from the linux command line. (For me, the command "arch" gave a different and unhelpful result)
dpkg --print-architecture #result for me: amd64
I then googled "libxkbcommon-x11.so.0 ubuntu 18.04 amd64", and likewise for libxkbcommon-x11.so.0, which yields those packages on packages.ubuntu.com. That told me, in retrospect unsurprisingly, I'm missing packages called libxkbcommon-x11-0 and libxkbcommon0, and that installing those packages will include the needed files, but the dev versions will not. Then the solution:
sudo apt-get update
sudo apt-get install libxkbcommon0
sudo apt-get install libxkbcommon-x11-0
So, I spent about a day trying to figure out what was the issue; tried all the proposed solutions, but none of that worked like installing xcb libs or exporting Qt plugins folder. The solution that suggested to use QT_DEBUG_PLUGINS=1 to debug the issue didn't provide me a direct insight like in the answer - instead I was getting something about unresolved symbols within Qt5Core.
That gave me a hint, though: what if it's trying to use different files from different Qt installations? On my machine I had standard version installed in /home/username/Qt/ and some local builds within my project that I compiled by myself (I have other custom built kits as well in other locations). Whenever I tried to use any of the kits (installed by Qt maintenance tool or built by myself), I would get an "xcb error".
The solution was simple: provide the Qt path through CMAKE_PREFIX_PATH and not though Qt5_DIR as I did, and it solved the problem. Example:
cmake .. -DCMAKE_PREFIX_PATH=/home/username/Qt/5.11.1/gcc_64
I faced the same problem when after installing Viber. It had all required qt libraries in /opt/viber/plugins/.
I checked dependencies of /opt/viber/plugins/platforms/libqxcb.so and found missing dependencies. They were libxcb-render.so.0, libxcb-image.so.0, libxcb-icccm.so.4, libxcb-xkb.so.1
So I resolved my issue by installing missing packages with this libraries:
apt-get install libxcb-xkb1 libxcb-icccm4 libxcb-image0 libxcb-render-util0
I like the solution with qt.conf.
Put qt.conf near to the executable with next lines:
[Paths]
Prefix = /path/to/qtbase
And it works like a charm :^)
For a working example:
[Paths]
Prefix = /home/user/SDKS/Qt/5.6.2/5.6/gcc_64/
The documentation on this is here: https://doc.qt.io/qt-5/qt-conf.html
All you need to do is
pip uninstall PyQt5
and
conda install pyqt
Most of the problem of pyqt can be fixed by this simplest solution.
In my case, I needed to deploy two Qt apps on an Ubuntu virtualbox guest. One was command-line ("app"), the other GUI_based ("app_GUI").
I used "ldd app" to find out what the required libs are, and copied them
to the Ubuntu guest.
While the command-line executable "app" worked ok, the GUI-based executable crashed, giving
the "Failed to load platform plugin "xcb" error. I checked ldd for libxcb.so, but this too had no missing dependencies.
The problem seemed to be that while I did copy all the right libraries I accidentally had copied also libraries that were already present at the guest system.. meaning that (a) they were unnecessary to copy them in the first place and (b) worse, copying them produced incompatibilities between the install libraries.
Worse still, they were undetectable by ldd like I said..
The solution? Make sure that you copy libraries shown as missing by ldd and absolutely no extra libraries.
In my case missing header files were the reason libxcb was not built by Qt. Installing them according to https://wiki.qt.io/Building_Qt_5_from_Git#Linux.2FX11 resolved the issue:
yum install libxcb libxcb-devel xcb-util xcb-util-devel mesa-libGL-devel libxkbcommon-devel
Folks trying to get this started on Ubuntu 20.04 please try to run this and see if this solves the problem. This worked for me
sudo apt-get update -y
sudo apt-get install -y libxcb-xinerama0
I link all Qt stuff statically to the generic Linux builds of my open source projects. It makes life a bit easier. You just need to build static versions of Qt libraries first. Of course this cannot be applied to closed source software due to licensing issues. The deployment of Qt5 apps on Linux is currently a bit problematic, because Ubuntu 12.04, for example, doesn't have Qt5 libraries in the package repositories.
I had this problem, and on a hunch I removed the Qt Configs from my environment. I.e.,
rm -rf ~/.config/Qt*
Then I started qtcreator and it reconfigured itself with the existing state of the machine. It no longer remembered where my projects were, but that just meant I had to browse to them "for the first time" again.
But more importantly it built itself a coherent set of library paths, so I could rebuild and run my project executables again without the xcb or qxcb libraries going missing.
I faced the same situation, but on a Ubuntu 20.04 VM.
TL;DR: Check file permissions.
What I did:
I copied the Qt libs required to /usr/local/lib/x86_64-linux-gnu/ and added it to LD_LIBRARY_PATH
I copied the platforms folder from Qt to my application directory and added it to QT_PLUGIN_PATH
I ran ldd on the executable and in the offending libqxcb.so (ldd libqxcb.so), and it complains about some dependencies although ldconfig listed them as found.
linux-vdso.so.1 (0x00007ffee19af000)
libQt5XcbQpa.so.5 => not found
libfontconfig.so.1 => /lib/x86_64-linux-gnu/libfontconfig.so.1 (0x00007f7cb18fb000)
libfreetype.so.6 => /lib/x86_64-linux-gnu/libfreetype.so.6 (0x00007f7cb183c000)
libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x00007f7cb1820000)
libQt5Gui.so.5 => /usr/local/lib/x86_64-linux-gnu/libQt5Gui.so.5 (0x00007f7cb0fd4000)
libQt5DBus.so.5 => not found
I used export QT_DEBUG_PLUGINS=1 for further info. It complains about missing files, although they are there.
What I found:
For some reason, when copying to the VM through the shared folder the files permissions were not the correct ones.
Thus, I ran: sudo chmod 775 * on the libs and voilà.
I solved the issue through this https://github.com/NVlabs/instant-ngp/discussions/300
pip uninstall opencv-python
pip install opencv-python-headless
This seems to have been a problem with the cv2 Python package and how it loops in Qt
sudo ln -sf /usr/lib/...."adapt-it"..../qt5/plugins/platforms/ /usr/bin/
It creates the symbolic link it's missed. Good for QT ! Good for VLC !!

How to tell Visual Studio Code compiled from source where to find sqlite module?

I am building the Visual Studio Code from the source checked out from the git repository:
git clone https://github.com/microsoft/vscode
I am building using:
export NODE_OPTIONS=--max_old_space_size=2048
./scripts/npm.sh install --arch=armhf
./scripts/code.sh
I am using node 10.16.3 on a Raspberry PI 4, using Raspbian buster
There were no errors during build.
The installation downloads a precompiled version of electron on the first run.
However each time I try and run code, it starts but with an error:
[storage state.vscdb] open(): Unable to open DB due to Error: Cannot find module '../build/Release/sqlite
If I look in node_modules/vscode-sqlite3/build/Release/
I can see:
sqlite3.a
sqlite.a
It is unclear to me why electron/vscode cannot find this library. I would be greatful for any pointers on how to tell the runtime where to look for the modules.
On inspecting the build scripts and after many painful experiments, I've found and solved the 2 problems leading to this error.
The fact that .a static libraries are left behind hinted that some settings in the binding.gyp, config.gpy and/or makefiles are wrong, as Native Node Modules are normally dynamic libraries with an .node extension. One conditional line in the binding.gyp file under vscode-sqlite3 seems to the the culprit:
...
["target_arch=='arm'", {"type": "static_library"}]
...
Disable that line (by removing it or changing 'arm' to something else) and then run:
node-gyp configure
to regenerate the config.gpy file(s) under the build directory. Then build the module with:
node-gyp build
A sqlite.node will be generated in build/Release.
Unfortunately, the latest electron ABI version rarely matches that of the Node.js version. In my configuration, the electron ABI version is 72 (v6.0.12) but the latest stable Node version is for ABI 64. Therefore we have to do an electron-rebuild to update the sqlite.node to match the electron version.
To do this, you would have to first install electron-rebuild (yarn add electron-rebuild) then run electron-rebuild by giving supplying explicitly the version number of the electron binary that vscode downloaded:
electron-rebuild -v 6.0.12 -m /home/dev/vscode -o vscode-sqlite3
Of course you would have to state the version number of your particular version of electron you are building for.
(Please look up electron-rebuild --help for the meaning of the options. It takes a while to rebuild the binary module...)
The resulting sqlite.node can then be moved into the build/Release/. directory under the vscode project directory. Voila, we have a working latest version VS-Code for Raspbian!

Where to install "guile-git" on Ubuntu 14?

I got stuck installing "git clone https://gitlab.com/guile-git/guile-git.git". In which directory is this supposed to be cloned and installed?
Dunno if you're still looking for an answer but it doesn't seem you need this installed to install guix; the read-me of the repository says that you can install it via guix. guix is an agnostic package manager that you can install on any Linux distribution alongside the default package manager and guix is the default package manager of the GuixSD operating system (https://www.gnu.org/software/guix/).
If you're on a distro which doesn't use guix, you may not want to install guix (I've yet to find reason enough to, yet); if you use a lot of GNU tools or Guile (some Guile packages are available through guix), you may want to.
Most repositories that don't have a binary for you to run follow the build process of configure, make, and [sudo ]make install.
I cloned the repository, myself, and find that this one does, as well.
Get a terminal (if you haven't been using one, yet) and cd into the directory you cloned the repository to and then cd into the guile-git directory (cd guile-git).
If we do ls -l, we'll see that the only executable file there is the bootstrap one; I've never seen one before but doing ./bootstrap generates the configure file and sets up the make process for us. So now back in familiar territory.
Given these are Guile files, we'll probably want to install this under the same prefix as where Guile is installed so run which guile. I believe, if you install it under Ubuntu (I'm running Linux Mint), it'll install to /usr/bin/ but, if you install it manually, it'll install to /usr/local/bin/.
The latter is where mine is and that's the default prefix that configure uses so I can just do ./configure; if you wanted to install it under /usr/, run /.configure --prefix=/usr/.
This'll verify that all of the necessary libraries and programs that guile-git needs are installed and properly setup. Heads up that configure balked at me over not having the Guile module bytestructures installed (https://github.com/TaylanUB/scheme-bytestructures) so you may need to do that.
I'm not going to run through everything to get it installed but, once you can run it without any errors, run make to build it within the directory.
If you want to install it permanently on your computer with the rest of your operating system able to detect it, run make install. Since you'll likely've specified a directory under /usr, you'll have to do sudo make install so that the make process can have permissions to install under /usr/local or /usr.
Sorry if I reiterated anything you already knew; 'just didn't want to assume you knew something and result in confusion.

%1 is not a valid Win32 application.. Sqlite3 in Electron app

I’m trying to get sqlite3 to work in an electron app running on Windows7 and 10. Running the following command, I was able to create electron-v1.7-win32-x64\node_sqlite3.node
cd node_modules/sqlite3 && sudo npm install nan
&& sudo npm run prepublish && sudo node-gyp configure --module_name=node_sqlite3 --module_path=…/lib/binding/electron-v1.7-win32-x64
&& node-gyp rebuild --target=1.6.11 --arch=x64 --target_platform=win32 --dist-url=https://atom.io/download/atom-shell
--module_name=node_sqlite3 --module_path=…/lib/binding/electron-v1.7-win32-x64
However, I get Uncaught Error: %1 is not a valid Win32 application. \\?\c:\folder\ppt_win32-x64\resources\app\node_modules\sqlite3\lib\binding\electron-v1.7-win32-x64\node_sqlite3.node.
My node version is v7.4.0. Electron v1.6.11.
I was trying to compile for windows from mi Mac and I had that problem too, but after some readings I figured out how to proceed, and after all I can say that I got it. Yesterday I spent all day setting up a windows virtual machine in my (other) Linux laptop (I used my linux laptop just because my mac was exhausted in storage...). I was having too a problem with the preloadScript from electron main process in windows, Cant found the script, it was solved too.
Anyway, I think the library node printer from #tojocky is well maintained, in other hand in the electron-builder documentation they say that you should compile in native for natural reasons. Once you will have it, you'll see that it's a cleaner and pragmatic solution ...
This was my entire process, I hope it helps to someone having the same issue:
Get VirtualBox (or Parallels but is not free)
Get iso for W10
Create a VM with this W10 iso, and you should give to this VM some storage (because some dependency that you'll need to compile), I have assigned 60gb to this VM
Once I had that VM running, I just installed in that machine Visual Studio 2017 (with their build-tools included, it's necessary)
And then, I used CMD to make the rest
Install NodeJS (and NPM, but it comes with)
Install node-gyp globally
Install Python 2.7
Clone your project from git (in my case)
npm i (in your project), you should have as npm dependency in your package.json the module electron-builder of course. (here I had some troubles because when node-gyp tried to rebuild printer to generate the binary for windows it was failing, this was because it was imposible to find the python executable, so if you face this problem you should add it like:npm config set python "c:\Python27\python.exe" in my case )
Then try again npm i and Voila!
If you still having error you can rebuild the native dependency as well, run:
node-gyp rebuild --target=YOUR_ELECTRON_TARGET[eg: 1.8.4] --arch=YOUR_ARCH_TARGET[eg: x64 | ia32] --dist-url=https://atom.io/download/atom-shell
After all, you should make the build using electron-builder, in my case my npm script command was build --win --x64 but you can use the --ia32 flag as well for 32bits

Building SQLITE for the Nodewebkit (Using express.js)

I am having problems compiling SQLite for use with Nodewebkit. After research, it seems that I am having wrong versions of the programs. So I have:
- Node
- NW
- SQLite
Apparently there must be certain version of each of the mentioned programs to make it work.
What versions of the programs I must have, so I can run this command:
npm install sqlite3 --build-from-source --runtime=node-webkit --target_arch=ia32 --target=0.12.3
This link suggests I should have NW version 0.8.x. But I cant find it for download. Or maybe that is not the problem at all...
I build on Mac using node-webkit v0.12.3 using the following commands:
sudo npm install nw-gyp -g
npm install sqlite3 --build-from-source --runtime=node-webkit --target_arch=ia32 --target=0.12.3
First, make sure you installed nw-gyp globally. Then, run the command either in the directory containing node-webkit executables (nwjs), or in a subfolder of that folder.
Running the command should then create a node_modules folder in the same directory as the binaries, containing the sqlite3 module.

Resources