Hmm.. just the presence of a segfault isn't too helpful at tracking down the error. Does the device come with gdb? If you are familiar could you run it in gdb to find out where the error is?

It really comes preinstalled with fibers? That's interesting because I've never heard of this before. Maybe you could contact the developers and see what they did to get it to build?

from node-fibers.

Hmm. I thought it was pre-installed, but maybe it's not. It's meant to be, at some point certainly.

jadonk/bonescript@f246a72

from node-fibers.

Looks like maybe it doesn't compile at all under 0.4.12.

fibers/src# make
g++ -march=armv7-a -mno-thumb-interwork -fno-tree-sink -Wno-psabi -marm -fPIC -c -o coroutine.o coroutine.cc
In file included from coroutine.h:4:0,
                 from coroutine.cc:1:
libcoro/coro.h:220:1: error: 'error' does not name a type
In file included from coroutine.cc:1:0:
coroutine.h:14:16: error: field 'context' has incomplete type
coroutine.cc:14:41: warning: converting to non-pointer type 'pthread_key_t' from NULL
coroutine.cc:15:40: warning: converting to non-pointer type 'pthread_key_t' from NULL
coroutine.cc: In constructor 'Coroutine::Coroutine()':
coroutine.cc:62:15: error: 'context' was not declared in this scope
coroutine.cc: In constructor 'Coroutine::Coroutine(void (&)(void*), void*)':
coroutine.cc:69:15: error: 'context' was not declared in this scope
coroutine.cc: In destructor 'Coroutine::~Coroutine()':
coroutine.cc:73:16: error: 'context' was not declared in this scope
coroutine.cc:73:23: error: 'coro_destroy' was not declared in this scope
coroutine.cc: In member function 'void Coroutine::transfer(Coroutine&)':
coroutine.cc:118:17: error: 'context' was not declared in this scope
coroutine.cc:118:32: error: 'class Coroutine' has no member named 'context'
coroutine.cc:118:39: error: 'coro_transfer' was not declared in this scope
make: *** [coroutine.o] Error 1

from node-fibers.

The error you're seing there is because the platform you are running is unknown. See in platform.mk it looks at process.platform to determine what build flag to pass to libcoro.

Also just to make sure, if you're using node 0.4.x you have to compile with the 0.5.x branch of node-fibers.

from node-fibers.

FWIW, we're stuck on node 0.4.x due to cloud9

from node-fibers.

Couldn't we run cloud9 under 0.4.x and bonescript under 0.6.x?

from node-fibers.

Sadly not, but there's https://github.com/ajaxorg/cloud9/pull/726 which should fix cloud9

from node-fibers.

FYI, I was able to build node-fibers on the board and use it with node 0.4.x. As mentioned earlier, you have to use an older version of node-fibers. It doesn't come installed on the board--instead bonescript simply recommends installing it. Hopefully the cloud9 issue will be resolved soon and we can move to node 0.6.x.

from node-fibers.

node-fibers is x86 only, since -m32 and -m64 are x86 only flags for gcc

from node-fibers.

Cool. Did it install cleanly out of npm? I have node 0.6.6 running on the board but node-fibers doesn't install with a npm install fibers.

from node-fibers.

I am running debian sid armel on my beaglebone. Have installed node 0.6.6 from debian and npm 1.1.0-beta-4. doing an npm install fibers results in the compile trying to use x86 flags for the compile phase and thus failing the build. Do you need the output from the npm command ?

from node-fibers.

I don't really need any more output at this point. There is nothing I can do to fix this problem for you guys without having one these systems in front of me. These build issues are hardly significant at all, so if you are interested please try and get it working and post the the results in this thread when you have success!

Here's some pointers:

• Remove incompatible build flags (I've heard -minline-string-ops is one)
• Fix detection of architecture to use -marm instead of -m64 or -m32
• Fix platform detection and ensure that -DCORO_ is included in the build

You would probably end up making most of these changes in platform.mk.

from node-fibers.

Ok, I have modified platform.mk thus:

I know nothing about scons, waf, or autoconf. Sorry.

NODE_PREFIX := $(shell echo "console.log(require('path').dirname(require('path').dirname(process.execPath)))" | node)
NODE_PLATFORM := $(shell echo "console.log(process.platform.replace('2', ''))" | node)
NODE_BITS := $(shell file echo "console.log(process.execPath)" | node | egrep -o '[0-9]{2}-bit' | cut -c-2)
NODE_TYPE := $(shell echo "console.log(process.env.NODETYPE)" | node)

CPPFLAGS = -Wall -Wno-deprecated-declarations -I$(NODE_PREFIX)/include -I$(NODE_PREFIX)/include/node
ifdef DEBUG
CPPFLAGS += -ggdb -O0
else
CPPFLAGS += -g -O3
ifneq ($(NODE_TYPE), arm)
CPPFLAGS += -minline-all-stringops
endif
endif

ifeq ($(NODE_BITS), )
ifeq ($(NODE_TYPE), arm)
CPPFLAGS += -marm
else
CPPFLAGS += -m32
endif
endif
ifeq ($(NODE_BITS), 32)
ifeq ($(NODE_TYPE), arm)
CPPFLAGS += -marm
else
CPPFLAGS += -m32
endif
endif
ifeq ($(NODE_BITS), 64)
CPPFLAGS += -m64
endif

ifeq ($(NODE_PLATFORM), linux)
# SJLJ in linux = hangs & segfaults
CPPFLAGS += -DCORO_UCONTEXT
endif
ifeq ($(NODE_PLATFORM), sunos)
CPPFLAGS += -DCORO_UCONTEXT
endif
ifeq ($(NODE_PLATFORM), darwin)
# UCONTEXT in os x = hangs & segfaults :(
CPPFLAGS += -DCORO_SJLJ
endif

to compile you will need to do an export NODETYPE=arm as I couldn't get process.env.HOSTTYPE or process.env.OSTYPE to give me anything but undefined despite them being in the environment.

I now get an error when running ./test.sh already-running.js but I think the code has compiled ok

from node-fibers.

actually -marm is harmfull. You don't need any flags when building natively.

from node-fibers.

I have taken this out now below is the part of the platform.mk suitably modified

ifeq ($(NODE_BITS), )
ifneq ($(NODE_TYPE), arm)
CPPFLAGS += -m32
endif
endif
ifeq ($(NODE_BITS), 32)
ifneq ($(NODE_TYPE), arm)
CPPFLAGS += -m32
endif
endif
ifeq ($(NODE_BITS), 64)
CPPFLAGS += -m64
endif

from node-fibers.

Are you guys testing this on node 0.4.x or 0.6.x? If it is on node 0.4.x you are using the 0.5 branch of fibers yeah? In that case you should cherry-pick cadde66 and rerun the tests to get better output.

from node-fibers.

I'm using node 0.6.6 and the latest git fibers from the instructions on the main page. I had tried the NPM install first before fetching the code.

from node-fibers.

Just run the test.sh again and no longer get a fail message but running the tests on their own gets a segmentation fault

from node-fibers.

I have been looking at the code for coroutine.cc and realised that I needed CORO_PTHREAD to be defined to make the .run construct in the test to run. I have modified the platform.mk file as below and now the code compiles and the test all pass. So i now have it running under debian sid on a beaglebone.

NODE_PREFIX := $(shell echo "console.log(require('path').dirname(require('path').dirname(process.execPath)))" | node)
NODE_PLATFORM := $(shell echo "console.log(process.platform.replace('2', ''))" | node)
NODE_BITS := $(shell file echo "console.log(process.execPath)" | node | egrep -o '[0-9]{2}-bit' | cut -c-2)
NODE_TYPE := $(shell echo "console.log(process.env.NODETYPE)" | node)

CPPFLAGS = -Wall -Wno-deprecated-declarations -I$(NODE_PREFIX)/include -I$(NODE_PREFIX)/include/node
ifdef DEBUG
CPPFLAGS += -ggdb -O0
else
CPPFLAGS += -g -O3
ifneq ($(NODE_TYPE), arm)
CPPFLAGS += -minline-all-stringops
endif
endif

ifeq ($(NODE_BITS), )
ifneq ($(NODE_TYPE), arm)
CPPFLAGS += -m32
endif
endif
ifeq ($(NODE_BITS), 32)
ifneq ($(NODE_TYPE), arm)
CPPFLAGS += -m32
endif
endif
ifeq ($(NODE_BITS), 64)
CPPFLAGS += -m64
endif

ifeq ($(NODE_PLATFORM), linux)
# SJLJ in linux = hangs & segfaults
ifeq ($(NODE_TYPE), arm)
CPPFLAGS += -DCORO_PTHREAD
else
CPPFLAGS += -DCORO_UCONTEXT
endif

endif
ifeq ($(NODE_PLATFORM), sunos)
CPPFLAGS += -DCORO_UCONTEXT
endif
ifeq ($(NODE_PLATFORM), darwin)
# UCONTEXT in os x = hangs & segfaults :(
CPPFLAGS += -DCORO_SJLJ
endif

from node-fibers.

Interesting, and DCORO_SJLJ don't work? DCORO_PTHREADS will be quite a bit slower than the other methods.

from node-fibers.

I've just tried CORO_SJLJ and not all the test pass. already_running.js, finish-multiple.js pool.js and stack-overflow.js all fail the test.

from node-fibers.

Dang. Well I'm confident that someone could get a native solution working on arm if the need came. For many applications the speed difference of CORO_PTHREADS vs CORO_UCONTEXT won't matter. I'll see about getting this into the makefile for the next release, thanks!

from node-fibers.

There is still one improvement to be made.Change the code detecting the NODE_TYPE from $(shell echo "console.log(process.env.NODETYPE)" | node) to use either the HOSTTYPE or OSTYPE that come predefined in the environment of a linux box. I tried using these but could not get the process.env command to get them even though PATH and my variable NODETYPE do work.

from node-fibers.