Skip to content
This repository

Unable to build on SheevaPlug (ARM) #2131

Closed
blalor opened this Issue November 16, 2011 · 56 comments
Brian Lalor

System config info: https://gist.github.com/509ed97da39c52fca1fe#file_0_sysinfo.txt

I'm building from master (cf2ee19).

Initial make after configure fails: https://gist.github.com/509ed97da39c52fca1fe#file_4_compile_output.txt

Per @bnoordhuis's comment on #1566 I ran:

perl -i -pe "s/'-m32'//g" $(find -name \*.gypi) 

The build now fails like this:

In file included from ../deps/v8/src/v8globals.h:31,
                 from ../deps/v8/src/v8.h:53,
                 from /home/blalor/nodejs/out/Release/obj/gen/libraries.cc:7:
../deps/v8/src/globals.h:113:2: error: #error Target architecture ia32 is only supported on ia32 host
make[1]: *** [/home/blalor/nodejs/out/Release/obj.host/v8_nosnapshot/gen/libraries.o] Error 1
make[1]: Leaving directory `/home/blalor/nodejs/out'
make: *** [all] Error 2
Brian Lalor

options.gypi modified by hand thusly. Now getting tons of undefined reference to … errors; check 'em here.

At this point, I'm stuck.

current build process

  1. clean: git ls-files --other | xargs rm
  2. configure: ./configure --prefix=/opt/local/nodejs --without-ssl
  3. tweak options.gypi
  4. invoke make with overrides (in bash shell):
    E="-march=armv5t -mfloat-abi=soft"; make CFLAGS="$E" CCFLAGS="$E" CXXFLAGS="$E"
Ben Noordhuis

Now getting tons of undefined reference to … errors

Can you try this patch? It seems v8 needs some guidance on what platform to build for.

diff --git a/common.gypi b/common.gypi
index 0a4183b..3db618b 100644
--- a/common.gypi
+++ b/common.gypi
@@ -6,6 +6,7 @@
     'library%': 'static_library',    # allow override to 'shared_library' for DLL/.so builds
     'component%': 'static_library',  # NB. these names match with what V8 expects
     'msvs_multi_core_compile': '0',  # we do enable multicore compiles, but not using the V8 way
+    'v8_target_arch%': '<(target_arch)',
   },

   'target_defaults': {
Brian Lalor
Ben Noordhuis

Okay, you'll have to play around with it. v8_target_arch is the key here, deps/v8/tools/gyp/v8.gyp depends on it being set to "arm" to compile the right sources.

Brian Lalor

Should options.gypi be setting target_arch and host_arch to arm or armv5t? The only real logic I see in the v8 config related to arm specifies armv7. Does v8 even support this architecture?

Ben Noordhuis

Should options.gypi be setting target_arch and host_arch to arm or armv5t

arm

The only real logic I see in the v8 config related to arm specifies armv7. Does v8 even support this architecture?

armv5t? Yes.

Brian Lalor

I changed target_arch and host_arch in options.gypi to "arm"; options.gypi in its entirety:

{
  "variables": {
    "node_prefix": "/opt/local/nodejs", 
    "node_shared_cares": "false", 
    "node_shared_v8": "false", 
    "node_use_openssl": "false", 
    "target_arch": "arm", 
    "node_debug": "false", 
    "host_arch": "arm", 
    "v8_use_snapshot": "true", 
    "node_use_dtrace": "false"
  }, 
  "target_defaults": {
    "libraries": [
      "-lz"
    ], 
    "defines": [], 
    "cflags": [], 
    "include_dirs": []
  }
}

make now dies with:

[blalor@pepe ~/nodejs]> E="-march=armv5t -mfloat-abi=soft"; make CFLAGS="$E" CCFLAGS="$E" CXXFLAGS="$E"
tools/gyp_node -f make
['-f', 'make', '/home/blalor/nodejs/node.gyp', '-I', '/home/blalor/nodejs/common.gypi', '-I', '/home/blalor/nodejs/options.gypi', '--depth=.', '--generator-output', '/home/blalor/nodejs/out', '-Goutput_dir=/home/blalor/nodejs/out', '-Dtarget_arch=ia32', '-Dcomponent=static_library', '-Dlibrary=static_library']
Traceback (most recent call last):
  File "tools/gyp_node", line 60, in <module>
    run_gyp(gyp_args)
  File "tools/gyp_node", line 18, in run_gyp
    rc = gyp.main(args)
  File "./tools/gyp/pylib/gyp/__init__.py", line 465, in main
    options.circular_check)
  File "./tools/gyp/pylib/gyp/__init__.py", line 101, in Load
    depth, generator_input_info, check, circular_check)
  File "./tools/gyp/pylib/gyp/input.py", line 2265, in Load
    depth, check)
  File "./tools/gyp/pylib/gyp/input.py", line 435, in LoadTargetBuildFile
    includes, depth, check)
  File "./tools/gyp/pylib/gyp/input.py", line 389, in LoadTargetBuildFile
    build_file_path)
  File "./tools/gyp/pylib/gyp/input.py", line 986, in ProcessVariablesAndConditionsInDict
    ProcessConditionsInDict(the_dict, is_late, variables, build_file)
  File "./tools/gyp/pylib/gyp/input.py", line 863, in ProcessConditionsInDict
    variables, build_file)
  File "./tools/gyp/pylib/gyp/input.py", line 1012, in ProcessVariablesAndConditionsInDict
    build_file)
  File "./tools/gyp/pylib/gyp/input.py", line 1027, in ProcessVariablesAndConditionsInList
    ProcessVariablesAndConditionsInDict(item, is_late, variables, build_file)
  File "./tools/gyp/pylib/gyp/input.py", line 1012, in ProcessVariablesAndConditionsInDict
    build_file)
  File "./tools/gyp/pylib/gyp/input.py", line 1027, in ProcessVariablesAndConditionsInList
    ProcessVariablesAndConditionsInDict(item, is_late, variables, build_file)
  File "./tools/gyp/pylib/gyp/input.py", line 986, in ProcessVariablesAndConditionsInDict
    ProcessConditionsInDict(the_dict, is_late, variables, build_file)
  File "./tools/gyp/pylib/gyp/input.py", line 863, in ProcessConditionsInDict
    variables, build_file)
  File "./tools/gyp/pylib/gyp/input.py", line 986, in ProcessVariablesAndConditionsInDict
    ProcessConditionsInDict(the_dict, is_late, variables, build_file)
  File "./tools/gyp/pylib/gyp/input.py", line 844, in ProcessConditionsInDict
    if eval(ast_code, {'__builtins__': None}, variables):
  File "<string>", line 1, in <module>
NameError: name 'armv7' is not defined while evaluating condition 'armv7==1' in /home/blalor/nodejs/deps/v8/tools/gyp/v8-node.gyp while loading dependencies of /home/blalor/nodejs/node.gyp while trying to load /home/blalor/nodejs/node.gyp
make: *** [all] Error 1

(same result with and without the extra flags on the make commandline).

Current patch is here. I've tried a few different variations of arm and armv5t with the various *_arch flags in the v8 source without luck, and occasionally reproducing the above stack trace.

Philip Cali

I was able to build the latest stable (v0.6.6) on Debian squeeze running in an ARM emulator.

I passed -march=armv5t into the CCFLAGS, and forced -mfloat-abi=soft when building v8. Changing the SConstruct file in deps/v8 was all that required for this build.

Afterwards, I copied the example http server located here http://nodejs.org/docs/v0.2.5/api.html, and tested it:

> ./node example.js &
[1] 4344
Server running at http://127.0.0.1:8124
> curl http://127.0.0.1:8124
Hello Word
> kill -9 4344
[1]+ Killed        ./node example.js

I'm not sure if that will help with your build, but I thought I would share my experience.

Brian Lalor

@philcali can you post the exact steps you took to get it v0.6.6 to build on ARM?

Philip Cali

Absolutely.

  • Upon successful debian installation, you need to install pkg-config so node can pick up the openssl libs (if you want ssl, otherwise disregard this step):
> su
> apt-get install pkg-config
> exit
  • Download the latest node source:
> mkdir tmp; cd tmp
> wget http://nodejs.org/dist/v0.6.6/node-v0.6.6.tar.gz
> tar -xvf node-v0.6.6.tar.gz
> rm node-v0.6.6.tar.gz
> cd node-v0.6.6
  • I had to edit deps/v8/SConstruct to get v8 to compile properly. Once this worked for me, I did not investigate other ways to pass these options along. Anyway, on line 82, add -march=armv5t or:
80 'gcc': {
81      'all': {
82        'CCFLAGS': ['$DIALECTFLAGS', '$WARNINGFLAGS', '-march=armv5t'],
83        'CXXFLAGS': ['-fno-rtti', '-fno-exceptions'],
84      },
  • I had to force -mfloat-abi=soft in the v8 build, by changing the default on line 1083 to soft, or:
1081  'armeabi': {
1082    'values': ['hard', 'softfp', 'soft'],
1083    'default': 'soft',
1084    'help': 'generate calling conventiont according to selected ARM EABI variant'
  • You're ready to run ./configure now. If the compile fails at snapshot.cc, then compile without it by passing --without-snapshot. I'm pretty sure I did without snapshot because startup times wasn't important to what I'm experimenting with.
> ./configure --without-snapshot
  • Everything should pass. If everything passes, then it's vanilla building time:
> make
  • Run your tests
  • Profit!
Paul Sims

@philcali I get this error on make

make -C out BUILDTYPE=Release
make[1]: Entering directory `/home/app/src/node/out'
CC(target) /home/app/src/node/out/Release/obj.target/http_parser/deps/http_parser/http_parser.o
cc1: error: unrecognized command line option "-m32"
make[1]: *** [/home/app/src/node/out/Release/obj.target/http_parser/deps/http_parser/http_parser.o] Error 1
make[1]: Leaving directory `/home/app/src/node/out'
make: *** [node] Error 2

Which version of debian are you running?

Philip Cali

I'm running debian squeeze (running in ARM versatile mode, I should mention). When I run a uname -a in the emulator, I get:

Linux debian 2.6.32-5-versatile #1 Tue Oct 4 01:32:59 UTC 2011 armv5etj1 GNU/Linux

On a slightly different note, I used this exact emulator with similar build instructions to build a working node executable (v0.6.6) for my android tablet (2.6.36 armv7a device). The steps I used for that is a little bit more complicated and hackish, though.

Brian Lalor
Jurriaan Pruis

Works perfectly on my Sheevaplug :)

Paul Sims

@jurriaan @blalor could you post results of uname -a? Be interested to see if my problems are based on environment.
I have spent way too much time trying to get .6 running. Cheers

Brian Lalor

Sure thing, @paulisimo:

Linux pepe 2.6.37 #3 PREEMPT Sat Jan 22 22:39:36 MST 2011 armv5tel armv5tel armv5tel GNU/Linux
Jurriaan Pruis

Here's mine:

Linux JurriServer 3.1.5 #4 PREEMPT Sat Dec 10 17:36:43 MST 2011 armv5tel GNU/Linux

@philcali's instructions worked perfectly for me

Evan Tahler

Hi Everyone!

I've been trying to build node on a Phidget board (emdebian, ARM) for a while now and @philcali has the best/closest guide I've found so far, but I'm still unable to get though make :(

uname -a => Linux phidgetsbc 2.6.36.3 #1 PREEMPT Wed Mar 16 15:01:07 MDT 2011 armv4tl GNU/Linux

Some additional steps I've needed to add:

  • 52MB of ram is not enough. I've added 256MB of swap to the system via usb stick
    • dd if=/dev/zero of=/media/usb1/swapfile bs=1M count=256
    • mkswap /media/usb1/swapfile
    • swapon /media/usb1/swapfile
  • export JOBS=1 because the CPU is tiny

I can get though ./configure --without-snapshot with all green, but I always fail on make's step 5 (the step which uses V8's SConscript). I've made the 2 changes per @philcali's advice. I seem to always segfault:

/root/node-v0.6.7/deps/v8/src/api.cc: In member function 'v8::Local<v8::Value> v8::Script::Id()':
/root/node-v0.6.7/deps/v8/src/api.cc:6102: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See <file:///usr/share/doc/gcc-4.4/README.Bugs> for instructions.
scons: *** [obj/release/api.o] Error 1
scons: building terminated because of errors.
Segmentation fault
Waf: Leaving directory `/root/node-v0.6.7/out'
Build failed:  -> task failed (err #139): 
    {task: libv8.a SConstruct -> libv8.a}

Any advice?!

More details to my install procedure are here [[ https://gist.github.com/1574158 ]]

Ben Noordhuis

@evantahler: You're probably running out of memory, gcc doesn't handle that well.

Evan Tahler

@bnoordhuis Thanks for the idea.

Some of my earlier problems (not listed here) were due to running out of ram with GCC. That lead me to add a lot of swap space to the system. I've run make a few times while watching the resources (htop) and I do end up using 100% of the system ram, but I'm never over 20% utilization on SWAP. I also thought I might be running out of disc space, so I ran the whole make process on a mounted external drive, but that wasn't it either.

Brian Lalor

@evantahler On such a constrained system, you might really benefit from setting up a cross-compiler toolchain on a more powerful computer…

Paul Sims

I have finally got 0.6.7 to build and install on sheevaplug. All worked ONCE i had done a full apt-get update / upgrade. Just updating via aptitude was not enough (having 2 package managers the same but different is something i don't fully understand)

Anyhow following @philcali process worked once everything was updated. Thanks to @blalor & @jurriaan for your support.

Jurriaan Pruis

Why can't this be fixed upstream?

Ben Noordhuis

Why can't this be fixed upstream?

If by upstream you mean Node or V8, we take patches for Node. V8's issue tracker is here.

Alternatively, someone could set up a repo with prepackaged ARM debs.

Evan Tahler

Progress!
I was able to build V8 for armv4 with cross-compiling on a more powerful Debian system. I can bring that onto my ARM device, and I get get though the entire make procedure. However, running node produces the feared Illegal instruction message.

Waf: Leaving directory `/root/node-v0.6.7/out'
'build' finished successfully (13m18.242s)
-rwxr-xr-x 1 root root 3.6M Jan 15 01:38 out/Release/node

root@phidgetsbc:~/node-v0.6.7# out/Release/node 
Illegal instruction

My steps are all here: https://gist.github.com/1574158

Any advice?

Ben Noordhuis

@evantahler: Run it through gdb and check what the offending instruction is.

gdb --args out/Release/node
run
# wait for the crash
disassemble
Evan Tahler

@bnoordhuis good idea! (and thank you for taking the time to help!)

I've copied the whole decompile trace here [[ https://gist.github.com/1574158 ]], but it looks like the source of the problem is:

Program received signal SIGILL, Illegal instruction.
node::Platform::GetUptimeImpl () at ../src/platform_linux.cc:305
305     uptime += (double)now.tv_nsec / 1000000000.0;

That seems like a pretty basic operation, so I'm wondering if something went wrong with float flags (everything should have been compiled with software floating point [ softfp ]).

Ben Noordhuis

That seems like a pretty basic operation, so I'm wondering if something went wrong with float flags (everything should have been compiled with software floating point [ softfp ]).

It sure looks that way. You may need to specify -mfpu=<fpu-name> or compile with -mfloat-abi=soft instead (make sure that you compile V8 with armeabi=soft too).

Evan Tahler

@bnoordhuis Great Advice! It's working!!!

For those interested, here are the final steps: https://gist.github.com/1574158

Evan Tahler

Oh, and I guess I would now say that this is no longer an open issue, although it would be nice if the ./configure knew how to handle more of these "eccentric" chipsets.

Ben Noordhuis

although it would be nice if the ./configure knew how to handle more of these "eccentric" chipsets.

I'd accept a patch for that, provided it's based off the master branch and not too intrusive.

Thanks to this comment - With these modifications it went well further. Now I think its nearly completed (35/35). I try to compile 0.6.7 on arm of my synology DS409. Now I get following error, any suggestions?

root@srv-dionysius: /root/joyent-node-a9453ba # make
Waf: Entering directory `/root/joyent-node-a9453ba/out'
DEST_OS: linux
DEST_CPU: arm
Parallel Jobs: 1
Product type: program
[35/35] cxx_link: out/Release/src/node_main_5.o out/Release/src/node_5.o out/Release/src/node_buffer_5.o out/Release/src/node_javascript_5.o out/Release/src/node_extensions_5.o out/Release/src/node_http_parser_5.o out/Release/src/node_constants_5.o out/Release/src/node_file_5.o out/Release/src/node_script_5.o out/Release/src/node_os_5.o out/Release/src/node_dtrace_5.o out/Release/src/node_string_5.o out/Release/src/node_zlib_5.o out/Release/src/timer_wrap_5.o out/Release/src/handle_wrap_5.o out/Release/src/stream_wrap_5.o out/Release/src/tcp_wrap_5.o out/Release/src/udp_wrap_5.o out/Release/src/pipe_wrap_5.o out/Release/src/cares_wrap_5.o out/Release/src/tty_wrap_5.o out/Release/src/fs_event_wrap_5.o out/Release/src/process_wrap_5.o out/Release/src/v8_typed_array_5.o out/Release/src/node_signal_watcher_5.o out/Release/src/node_stat_watcher_5.o out/Release/src/node_io_watcher_5.o out/Release/src/platform_linux_5.o out/Release/src/node_crypto_5.o out/Release/deps/http_parser/http_parser_3.o -> out/Release/node
/opt/bin/g++ Release/src/node_main_5.o Release/src/node_5.o Release/src/node_buffer_5.o Release/src/node_javascript_5.o Release/src/node_extensions_5.o Release/src/node_http_parser_5.o Release/src/node_constants_5.o Release/src/node_file_5.o Release/src/node_script_5.o Release/src/node_os_5.o Release/src/node_dtrace_5.o Release/src/node_string_5.o Release/src/node_zlib_5.o Release/src/timer_wrap_5.o Release/src/handle_wrap_5.o Release/src/stream_wrap_5.o Release/src/tcp_wrap_5.o Release/src/udp_wrap_5.o Release/src/pipe_wrap_5.o Release/src/cares_wrap_5.o Release/src/tty_wrap_5.o Release/src/fs_event_wrap_5.o Release/src/process_wrap_5.o Release/src/v8_typed_array_5.o Release/src/node_signal_watcher_5.o Release/src/node_stat_watcher_5.o Release/src/node_io_watcher_5.o Release/src/platform_linux_5.o Release/src/node_crypto_5.o Release/deps/http_parser/http_parser_3.o -o /root/joyent-node-a9453ba/out/Release/node -lz -pthread -rdynamic /root/joyent-node-a9453ba/out/Release/libv8.a /root/joyent-node-a9453ba/out/Release/deps/uv/uv.a -L/opt/lib -L/usr/lib -L/usr/local/lib -Wl,-Bdynamic -lssl -lcrypto -ldl -lutil
Release/src/platform_linux_5.o: In function `node::Platform::GetUptimeImpl()':
/root/joyent-node-a9453ba/out/../src/platform_linux.cc:303: undefined reference to `clock_gettime'
/root/joyent-node-a9453ba/out/../src/platform_linux.cc:303: undefined reference to `clock_gettime'
/root/joyent-node-a9453ba/out/Release/deps/uv/uv.a(linux.o): In function `uv_hrtime':
/root/joyent-node-a9453ba/out/Release/deps/uv/src/unix/linux.c:136: undefined reference to `clock_gettime'
/root/joyent-node-a9453ba/out/Release/deps/uv/uv.a(ares__timeval.o): In function `ares__tvnow':
/root/joyent-node-a9453ba/out/Release/deps/uv/src/ares/ares__timeval.c:48: undefined reference to `clock_gettime'
/opt/lib/gcc/arm-none-linux-gnueabi/4.2.3/../../../../arm-none-linux-gnueabi/lib/libpthread.so: undefined reference to `__default_sa_restorer_v2@GLIBC_PRIVATE'
/opt/lib/gcc/arm-none-linux-gnueabi/4.2.3/../../../../arm-none-linux-gnueabi/lib/libpthread.so: undefined reference to `__default_sa_restorer_v1@GLIBC_PRIVATE'
/opt/lib/gcc/arm-none-linux-gnueabi/4.2.3/../../../../arm-none-linux-gnueabi/lib/libpthread.so: undefined reference to `__default_rt_sa_restorer_v2@GLIBC_PRIVATE'
/opt/lib/gcc/arm-none-linux-gnueabi/4.2.3/../../../../arm-none-linux-gnueabi/lib/libpthread.so: undefined reference to `__default_rt_sa_restorer_v1@GLIBC_PRIVATE'
collect2: ld returned 1 exit status
Waf: Leaving directory `/root/joyent-node-a9453ba/out'
Build failed:  -> task failed (err #1): 
    {task: cxx_link node_main_5.o,node_5.o,node_buffer_5.o,node_javascript_5.o,node_extensions_5.o,node_http_parser_5.o,node_constants_5.o,node_file_5.o,node_script_5.o,node_os_5.o,node_dtrace_5.o,node_string_5.o,node_zlib_5.o,timer_wrap_5.o,handle_wrap_5.o,stream_wrap_5.o,tcp_wrap_5.o,udp_wrap_5.o,pipe_wrap_5.o,cares_wrap_5.o,tty_wrap_5.o,fs_event_wrap_5.o,process_wrap_5.o,v8_typed_array_5.o,node_signal_watcher_5.o,node_stat_watcher_5.o,node_io_watcher_5.o,platform_linux_5.o,node_crypto_5.o,http_parser_3.o -> node}
make: *** [program] Error 1
root@srv-dionysius: /root/joyent-node-a9453ba # 
Ben Noordhuis

@Dionysius: With what kernel and glibc version is this?

Evan Tahler

Hey @Dionysius

Using the instructions you linked led me to a similar (indeterminate) error. That's why I took the route of making my changes at the shell level rather than just in the v8 scripts. It looks like you too might be having the same issues where you can get though the v8 compilation, but not node itself. Hopefully my notes above and this https://gist.github.com/1574158 might help

@bnoordhuis (I'm unsure about the first one | how to find that out?)

root@srv-dionysius: /root/joyent-node-a9453ba # ipkg list_installed | grep libc-dev
libc-dev - 2.5-5 - libc development files.
root@srv-dionysius: /root/joyent-node-a9453ba # uname -a
Linux srv-dionysius 2.6.32.12 #1955 Sat Nov 26 14:50:54 CST 2011 armv5tel GNU/Linux

@evantahler I will try this. For me it looks really complicated. Lets see what I can figure out and try myself

Ben Noordhuis

@Dionysius: glibc 2.5 is positively ancient (as in: over five years old by now). I could probably add a workaround for clock_gettime() but it seems you also have an outdated or broken pthreads library...

@bnoordhuis you're completely right. I think its waste of time to make a workaround for that. Either my source gets updated or i'll compile that to from scratch. Until then, my issuepart is abandoned. I'll comment once I've more.

danielchisholm

I just wanted to add my thanks to @philcali, his instructions allowed me to build node v0.6.9 on a trimslice (ARMv7). What a great, clear well-written post - thanks, Phil!

David Kemp

I'm still having problems with Date() returning various errors after @philcali's instructions. I've noticed (with v0.6.10 at least), there's a property for vfp3 in the SConstruct file, which I'm playing with.

David Kemp

Ok, so that flag made no difference on some of the math

> new Date()
Wed, 08 Feb 2012 21:09:00 GMT
> new Date()
undefined, 08 Feb 2012 16:59:7.204752364e-315 GMT
> new Date()
undefined, 08 Feb 2012 00:7.204752364e-315:07.204752364e-315 GMT
> new Date()
Thu, 08 Feb 2012 00:00:00 GMT
> new Date()
undefined, 08 Feb 2012 24:7.204752364e-315:7.204752364e-315 GMT
> new Date()
undefined, 08 Feb 2012 24:7.204752364e-315:7.204752364e-315 GMT

I guess this is an upstream issue as building the V8 shell results in the same issue.

Brian Wightman
2 ^ 3 ^ 4

is the xor operation (https://developer.mozilla.org/en/JavaScript/Reference/Operators/Operator_Precedence), not the exponentiation operation.

0010 ^ 0011 => 0001, 0001 ^ 0100 => 0101.

David Kemp

@MidLifeXis - my mistake. thanks

truedat101

Nice work by everyone here coming up with some solutions and documenting the various issues. I've been down the various roads myself. I agree with comment from @evantahler #2131 (comment) . How can we get something in place with so that we can get the issue assigned and closed ?

Paul Sims

In the process of updating my sheevaplug i decided to rebuild debian on a much larger sd card 2gb -- 16gb to handle putting a rails et al on there. That's all gone fairly well, but once again the nodejs install is a dog. I have been cloning it out of git and getting a lot of this...

NameError: name 'armv7' is not defined while evaluating condition 'armv7==1' in /home/app/src/node/deps/v8/tools/gyp/v8.gyp

This is including @philcali's deps/v8/sconstruct edits above.

Having better luck NOT using the git version and using wget instead. Just in case anyone is suffering as I have.

Michael Dillon

Following philcall 's instructions I have tried passing armv7l into -march= however I'm getting an error as follows:

cc1plus: error: bad value (armv7l) for -march switch

Here is my current system info:

Linux beaglebone 3.2.5+ #1 Mon Feb 13 19:22:44 CET 2012 armv7l GNU/Linux
Ben Noordhuis

@michaelcdillon: You can find the list of architecture names in man gcc. Try armv7 or armv7-a.

Michael Dillon

@bnoordhuis Thanks so much! Sorry I'm quite new to this embedded stuff.

Ben Noordhuis
seashorexxx

@bnoordhuis: Thank you for your reply. Sorry for that I could install node-v6.1.8 successfully and it works without error, then I deleted my post. Thank you gain.

Ben Noordhuis
Mathieu Gosbee

I've tried all of the solutions here, but the Issue above, #3382 still persists.

Ben Noordhuis

I've tried all of the solutions here, but the Issue above, #3382 still persists.

The problem is mainly that each ARM device is different in subtle ways, we can't test them all. Either send hardware our way or fix the issue yourself and forward the patch.

truedat101

Folks, curious for those still having troubles, have you explored getting off Debian/ARM7 or Ubuntu/ARM7 and onto a distro that both supports your hardware and maintains current packages for Node.js? I can recommend ArchLinuxARM for a variety of PlugComputer platforms ARM5 based, and additionally some non-plugcomputer devices ARM7 based. The guys on the project are into Node and keep a current package as soon as a new release hits the streets. I realize this isn't a solution for anyone who is building their own firmware or stuck on something like the Debian that ships with Plugs, but it is a viable option for people willing to try out some new firmware.

Current release
armv7/armv5 community nodejs 0.6.18-1 Evented I/O for V8 javascript

Stef Busking
bwrrp commented July 18, 2012

I have a sheevaplug with debian squeeze. I previously got a 0.6.7-ish node (I'm afraid I can't remember which version exactly) to compile and run without problems, and recently tried to upgrade to 0.8.x. The build works with the following:

./configure --without-snapshot
make CFLAGS+=-march=armv5t CXXFLAGS+=-march=armv5t

however, running make CFLAGS+=-march=armv5t CXXFLAGS+=-march=armv5t test after this results in several glibc errors, such as:

*** glibc detected *** out/Release/node: free(): invalid next size (fast): 0x006a4040 ***
*** glibc detected *** out/Release/node: free(): invalid next size (normal): 0x007e3180 ***
*** glibc detected *** out/Release/node: free(): invalid pointer: 0x007ec678 ***

This happens even on the latest checkout of the v0.8 branch (beb7425). Any ideas what I could be doing wrong here?

Ben Noordhuis

@Bwrrp Hook up the failing tests to gdb: gdb --args out/Release/node test/simple/test-that-fails.js. Start the test with r and, when glibc asserts, type bt full to get a backtrace and post that in a new issue. Hopefully that gives some insight.

Ben Noordhuis bnoordhuis closed this July 28, 2012
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.