can't install on raspberry pi 3

[hughjfchen]

When I tried to install lumo on the raspberry pi 3, it always said download failed. I've tried to install it through a proxy with no luck. I attached the npm_debug.log for reference.

[hughjfchen]

raspberry pi 3 node 7.7.2 npm 4.1.2

[hughjfchen]

I'd upgraded to node 7.8.0 and still met the same error. Anyone who'd tried to install lumo in pi can share any tips?

[anmonteiro]

Lumo still doesn't run on ARM.

I've tried to cross-compile Lumo for ARM before but didn't succeed at first and didn't spend too much time on it.

This is theoretically possible given we compile Node.js as part of the build process and Node supports ARM. Let me know if you wanna help out!

[hughjfchen]

Ok. So I've cloned the repo and tried to build it on my pi for three times. Each time the build failed on the same step with the "virtual memory exhausted: Cannot allocate memory" error. I googled this error but can't any real progress. Do we have to build nodejs again because we'd already had it installed?

[hughjfchen]

Extended the swap file to 1024m and tried again, now I got following error:

g++: internal compiler error: Killed (program cc1plus) Please submit a full bug report, with preprocessed source if appropriate. See file:///usr/share/doc/gcc-4.9/README.Bugs for instructions. make[1]: *** [/home/pi/lumo/tmp/node/7.7.1/node-v7.7.1/out/Release/obj.target/node/gen/node_javascript.o] Error 4

I don't know what to do next. Any tips?

[hughjfchen]

Interesting. I just found that it did generate the executable lumo under the build directory. I tried and found it really works. I don't know what potential issues it may have. I decided to play around with it first and will report back if I found something wrong.

[anmonteiro]

That is great, and a step in the direction of having Lumo on the rPi. However, I think we should try to cross-compile for ARM. That way we can do it in CI and builds should also be mich faster. That's where I was stuck when I tried.

[hughjfchen]

I totally agree that we should take the cross-compile direction. Last night,I tried to build 1.3.0 and it took over 3 hours although it finished the build without any problems. Can you give more details about the problem with cross-compile? I may give some help with this.

[anmonteiro]

@hughjfchen your help is much appreciated. My problem with cross compiling was about which packages to install and which options we needed to pass to Node.js's configure (through Nexe).

[jdeisenberg]

I am also trying to build Lumo on the Raspberry Pi 3, with a swap space of 4 GB. The compile dies with this error:

  g++ -pthread -rdynamic  -o /home/david/lumo/tmp/node/7.10.0/node-v7.10.0/out/Release/mkpeephole -Wl,--start-group /home/david/lumo/tmp/node/7.10.0/node-v7.10.0/out/Release/obj.target/mkpeephole/deps/v8/src/interpreter/bytecode-operands.o /home/david/lumo/tmp/node/7.10.0/node-v7.10.0/out/Release/obj.target/mkpeephole/deps/v8/src/interpreter/bytecodes.o /home/david/lumo/tmp/node/7.10.0/node-v7.10.0/out/Release/obj.target/mkpeephole/deps/v8/src/interpreter/mkpeephole.o /home/david/lumo/tmp/node/7.10.0/node-v7.10.0/out/Release/obj.target/deps/v8/src/libv8_libbase.a -static -ldl -lrt -Wl,--end-group
/usr/lib64/gcc/aarch64-suse-linux/4.8/../../../../aarch64-suse-linux/bin/ld: cannot find -ldl
/usr/lib64/gcc/aarch64-suse-linux/4.8/../../../../aarch64-suse-linux/bin/ld: cannot find -lrt
collect2: error: ld returned 1 exit status
deps/v8/src/mkpeephole.target.mk:126: recipe for target '/home/david/lumo/tmp/node/7.10.0/node-v7.10.0/out/Release/mkpeephole' failed
make[1]: *** [/home/david/lumo/tmp/node/7.10.0/node-v7.10.0/out/Release/mkpeephole] Error 1
make[1]: *** Waiting for unfinished jobs....
make[1]: Leaving directory '/home/david/lumo/tmp/node/7.10.0/node-v7.10.0/out'
Makefile:75: recipe for target 'node' failed
make: *** [node] Error 2
....> ERROR: The release executable has not been generated. This indicates a failure in the build process. There is likely additional information above.

Here is the content of the directory (I added symlinks to the libdl.so and librt.so in an attempt to get around the problem, but it did not work):

david@linux:/usr/aarch64-suse-linux/bin> ls -l
total 0
lrwxrwxrwx 1 root root 12 May  1 10:31 ar -> ../../bin/ar
lrwxrwxrwx 1 root root 12 May  1 10:31 as -> ../../bin/as
lrwxrwxrwx 1 root root 12 May  1 10:31 ld -> ../../bin/ld
lrwxrwxrwx 1 root root 20 May 29 21:54 libdl.so -> /lib64/libdl-2.22.so
lrwxrwxrwx 1 root root 20 May 29 21:53 librt.so -> /lib64/librt-2.22.so
lrwxrwxrwx 1 root root 12 May  1 10:31 nm -> ../../bin/nm
lrwxrwxrwx 1 root root 16 May  1 10:31 ranlib -> ../../bin/ranlib
lrwxrwxrwx 1 root root 15 May  1 10:31 strip -> ../../bin/strip

[Rovanion]

Same applies when compiling on my 32-bit Linux machine. I added 18GB RAM/swap to my machine, alas to no avail. The node build is probably hitting the 4GB virtual memory limit a 32-bit process can address.

[timfenney]

Hello all, happy to help at all if I can. @hughjfchen re. your 1024m swap file, that may not be enough; "g++: internal compiler error: Killed (program cc1plus)" sounds like it could be killed by Linux (at some non-deterministic point, perhaps). Have you tried with more swap, such as 4 or 8GB?

It looks to me like the build script uses "make -j 8", which means "use 8 parallel compiler processes", which seems a little excessive for building on the pi (I'm building on the 1 core Pi Zero W). The traditional wisdom was to use "-j n", where n is 2 x the core count. Perhaps 1 x the core count is more appropriate for the Pi, which is both memory constrained, and has less pipelining magic like Hyperthreading?

@anmonteiro -- is it possible to make this dynamic, or at least default to 8, with the ability to override with an environment variable? Also, I have noticed similar resource usage for java earlier in the build process (8 threads or so?), but I'm not sure what could be done about that.

[timfenney]

@jdeisenberg those paths look a little suspect to me; I think in particular linking libraries into a bin folder won't help.

It might be worth trying to add the absolute path to the directory containing your libraries to the LD_LIBRARY_PATH environment variable. Perhaps like this:

$ export LD_LIBRARY_PATH="$LD_LIBRARY_PATH:/path/to/lib/folder"

?

[arichiardi]

For reference there exists now an environment variable to build lumo against different node versions:

export NODE_BUILD_VERSION=8.10.0
boot release

Gets you there.

Having said that, I would be in super favor of just releasing the compiled js files with caches in the npm package for direct JS consumption (say using node target/bundle.js directly).

[anmonteiro]

https://chrislea.com/2018/08/20/cross-compiling-node-js-for-arm-on-ubuntu/