Finished porting (experimentally) core Node Js to Haiku


Hi all.

After doing myself a userland implementation for the epoll functions and several functions not present on Haiku (at least on my version), i got a working version of Node JS running in Haiku.

This is purely experimental and experienced some errors randomly (like <10% of the times i ran the interpreter, but they are still present), and some weird behavior on ansync output functions, probably because of my epoll hacks.

Here it passes the 50 test done by the executable cctest

Should pass in under 1 second, but the VM host antivirus wanted to make it slower by analyzing

Some command checks in Terminal console (i.e version + help):


Os (yep, still shows Linux for now), DNS and crypto modules running into the node REPL:




And a script execution, showing (voluntary) runtime failures,cat the file itself and a Webpositive load of the dynamic webpage it creates.


Code is closer to a canibalized version, and not so well made as other members (which tuned the Gypi files to include Haiku in the OS variables / lists, to name one good thing) but shows that implementing a bare minimum set of functions, uv, v8 can be compiled and work on this OS, and more Haiku-experienced people can made it rock :thinking:

Any thoughts / opinions / critic on this?


Create a proper port, try to upstream and write a recipe.


I have not Haiku skills to make a proper port. Specially the events part.

Might try from scratch to make this better, although i am not sure about upstream being accepted easily (too many places where Haiku would have to be “defined”). In any case, a recipe may worth the effort.

Npm is still missing tho, which makes this even less useful. I expected it to be compiled along the node exe.


Submit your changes as they are. People can review and help clean them up.


This post was flagged by the community and is temporarily hidden.


Yay, I finally have found some time and cleaned the code (a bit), and uploaded to a self not-official-node-fork repository on github, in case of reviews, curiosity or anything that’s wanted.

Link is up at:

GitHub Haiku NodeJs Repo

Version was just done modifying the official source repo, attempting to look like linux, toying with the includes. I put my code in the deps/compat folder, where I implemented the epoll functions using select and other system functions. This should have a Haiku version if wait for message functions work in a good way and so.

A clean compilation in the test VMS takes about 2-3 hours, so I made a release as zipped binaries for Node and NPM, which are working in 32bits haiku VMS (without errors aparently), available for anyone at:

Release (32bits)

Which is interesting is that this version of node (v11.0.0-pre) has WebAssembly support, so one might use this for some interesting uses in Haiku, like compiling c++ code to wasm in another os and run it here :thinking:

I guess it doesnt matter now but was one feature that i didnt expect to see.

Pst pst: i know we shall make a upstream clone and do changes, but this version might be used for learning or comparison too.

@extrowerk Related for your work in Libuv port (WIP issue), and since your efforts included a CMake compatible lib version, I added a Cmake entry for Haiku (in a correct way, imo, mirroring the changes seen on the configure files). If i’m right, you can change the WIP file with them and do a cmake build instead of configure & make, to get a easier recipe and % shown while doing so:

Uv modified CmakeList

@waddlesplash Sorry to bother the core bosses here for a possible non important stuff, but the errors that i was getting using the toy version of node or the cctest binaries were not in my code itself but in a subpart of v8 library, randomly, which is called snapshot.

Outcome in syslog came as:

KERN: vm_soft_fault: va 0x0 not covered by area in address space
KERN: vm_page_fault: vm_soft_fault returned error 'Bad address' on fault at 0x7, ip x2794ab9, write 0, user  1, thread 0x2df13

Full pastebin stacktrace

Which i saw in some tickets, without much further action other than being solved by updates in the meantime. Does it worth some research to prevent a future hidden error?


Those error messages are indeed bugs in the application; the reason they are not crash messages is usually because they are being handled by the application itself.


Aye aye sir. Just didnt want to find some surprises further in time, when/if v8 is used for other software on Haiku (hint hint: chromium).


@Pahefu Thanks for publishing your work on the Node.JS port! :slight_smile:

I’ve had a look at the deps folder in NodeJS, and it seems that they include their own version of several dependencies including V8. Are they using a forked version of V8 with their changes or are they pulling from upstream?

We could do with an update with our current V8 port (which is still very ancient).


My pleasure.

I have seen that they are close to the upstream version for libuv that extrowerk had in WIP for Haiku, so i guess that the node coders just took a copy to have the deps code frozen in time. Cannot really tell.

I think i did most of the changes on the libuv code (faking a linux version), and left v8 mostly untouched. In any case, you can go inside the v8 dep folder, copy to a place you like and do make/cmake operations to test a haiku version.

Includes the tests that we are trying to pass, with a 94 not-ok last time i checked on Haiku :thinking: You need to include a configure directive to enable them tho.


It is not my libuv port, the platform-specific patches are from @CodeforEvolution if i remember correctly, i just tried to maintain his patchset.


Good to see my patches are helping! I always meant to try to finish my port of libuv, but never had the time to finish it. Continue to feel free to use the patches as needed! :+1:


Yeah, i wanted to point at your issue,where @CodeforEvolution was also thanked :+1: , not changing ownership of the changes hehe.


Imust insert the mandatory warning about downloading untrusted binaries from the forums and running them.

People, use at your own risk!


Obviously right with the advice, that’s why the source code was up first.

Wish it could take less time in the compilation, so users can do themselves. Or having a recipe to get an official hpkg, but at experimental phase… :man_shrugging:

Edit @PulkoMandy . after thinking about it, the right advice would be warning against untrusted binaries from github repos (i pointed to the repo releases and not the file itself, i mean) :stuck_out_tongue: