Use J2V8 with Node.js v8.x

[drywolf]

@matiwinnetou @aschrijver @irbull

I create this issue to move the discussion about building J2V8 with Node.js v8.x over from #327 (and to avoid potential duplicate efforts)

With the tests in v8/debug/ disabled and the additions from @matiwinnetou I was now able to build & run tests successfully for Node.js v8.2.1 on the marked platforms below

By looking into android-configure and the Android NDK docs I hope it will be not too hard to get Android working also 🤞

(Android needs fixing, see this)

Platform	NJS Version	Build	Tests
Android x86	8.2.1	fails	-
	8.4.0	✓	some tests ok, some crash (same behavior as in 7.4.0)
Android ARM	8.2.1	TBD	TBD
	8.4.0	TBD	TBD
Alpine Linux	8.2.1	✓	all ok
	8.4.0	✓	some tests ok some crash the JVM
Linux	8.2.1	✓	all ok
	8.4.0	✓	some tests ok some crash the JVM
Mac OS	8.2.1	✓	all ok
	8.4.0	✓	some tests ok some crash the JVM
Windows	8.2.1	✓	all ok
	8.4.0	✓	all ok

[drywolf]

I spent quite some time yesterday and today the last couple of hours to figure out the right way to build a(ny) Node 8.x version with the latest Android NDK (nightly).

Just some minutes ago I've had the big breakthrough, and at least I got a Node.js build of a static lib that ran through till the end. Now the next step is to try and get CMake to correctly link to what was produced there ... so we are not done just yet. But at least for Node.js I think we might have something workable. I will keep posting updates as they roll in.

PS: I am building for x86/ia32 Android

[matiwinnetou]

Wow, didn't know it was that hard to build android with NodeJS 8.2.1. Great job!

I can add you as a collaborator to my branch: https://github.com/eclipsesource/J2V8/compare/master...matiwinnetou:nodejs8?expand=1

or how do we work together on this?

[drywolf]

I think I will push my current progress as a new branch to my fork tomorrow. I have to clean everything up a bit before I do that, because I had to try out so many different combinations of build configurations, right now it's just a huge pile of commented code with the few lines that finally worked somewhere in between 😆

At the moment I am sorting out the CMake build ... I have already made some progress, but now I am stuck with some stdlib header problems.

To elaborate ... the whole build is now using Clang and libc++ as the stdlib (this seems to be recommended for the newer NDK versions). If you try to build the latest Node.js with NDK+GCC you pretty early do hit a brick wall from what I (and others) experienced.

The error that I am now getting after CMake has generated the makefiles and Clang starts compiling the J2V8 project are the following:

Scanning dependencies of target j2v8
[ 50%] Building CXX object CMakeFiles/j2v8.dir/jni/com_eclipsesource_v8_V8Impl.cpp.o
In file included from /j2v8/jni/com_eclipsesource_v8_V8Impl.cpp:12:
In file included from /j2v8/node/deps/v8/include/libplatform/libplatform.h:9:
In file included from /j2v8/node/deps/v8/include/libplatform/v8-tracing.h:8:
In file included from /tmp/android-toolchain/bin/../include/c++/v1/fstream:169:
In file included from /tmp/android-toolchain/bin/../include/c++/v1/ostream:138:
In file included from /tmp/android-toolchain/bin/../include/c++/v1/ios:216:
In file included from /tmp/android-toolchain/bin/../include/c++/v1/__locale:15:
In file included from /tmp/android-toolchain/bin/../include/c++/v1/string:470:
In file included from /tmp/android-toolchain/bin/../include/c++/v1/string_view:171:
In file included from /tmp/android-toolchain/bin/../include/c++/v1/__string:56:
In file included from /tmp/android-toolchain/bin/../include/c++/v1/algorithm:640:
In file included from /tmp/android-toolchain/bin/../include/c++/v1/memory:629:
In file included from /tmp/android-toolchain/bin/../include/c++/v1/typeinfo:61:
In file included from /tmp/android-toolchain/bin/../include/c++/v1/exception:82:
/tmp/android-toolchain/bin/../include/c++/v1/cstdlib:114:9: error: no member named 'strtold' in the global namespace
using ::strtold;
      ~~^
/tmp/android-toolchain/bin/../include/c++/v1/cstdlib:132:9: error: no member named '_Exit' in the global namespace
using ::_Exit;
      ~~^
/tmp/android-toolchain/bin/../include/c++/v1/cstdlib:153:9: error: no member named 'at_quick_exit' in the global namespace
using ::at_quick_exit;
      ~~^
/tmp/android-toolchain/bin/../include/c++/v1/cstdlib:154:9: error: no member named 'quick_exit' in the global namespace
using ::quick_exit;
      ~~^
In file included from /j2v8/jni/com_eclipsesource_v8_V8Impl.cpp:12:
In file included from /j2v8/node/deps/v8/include/libplatform/libplatform.h:9:
In file included from /j2v8/node/deps/v8/include/libplatform/v8-tracing.h:8:
In file included from /tmp/android-toolchain/bin/../include/c++/v1/fstream:169:
In file included from /tmp/android-toolchain/bin/../include/c++/v1/ostream:138:
In file included from /tmp/android-toolchain/bin/../include/c++/v1/ios:216:
In file included from /tmp/android-toolchain/bin/../include/c++/v1/__locale:15:
In file included from /tmp/android-toolchain/bin/../include/c++/v1/string:474:
In file included from /tmp/android-toolchain/bin/../include/c++/v1/cwchar:107:
/tmp/android-toolchain/bin/../include/c++/v1/cwctype:68:9: error: no member named 'iswblank' in the global namespace; did you mean 'isblank'?
using ::iswblank;
      ~~^
/tmp/android-toolchain/sysroot/usr/include/ctype.h:66:5: note: 'isblank' declared here
int isblank(int);
    ^
In file included from /j2v8/jni/com_eclipsesource_v8_V8Impl.cpp:12:
In file included from /j2v8/node/deps/v8/include/libplatform/libplatform.h:9:
In file included from /j2v8/node/deps/v8/include/libplatform/v8-tracing.h:8:
In file included from /tmp/android-toolchain/bin/../include/c++/v1/fstream:169:
In file included from /tmp/android-toolchain/bin/../include/c++/v1/ostream:138:
In file included from /tmp/android-toolchain/bin/../include/c++/v1/ios:216:
In file included from /tmp/android-toolchain/bin/../include/c++/v1/__locale:15:
In file included from /tmp/android-toolchain/bin/../include/c++/v1/string:474:
/tmp/android-toolchain/bin/../include/c++/v1/cwchar:127:9: error: no member named 'vfwscanf' in the global namespace
using ::vfwscanf;
      ~~^
/tmp/android-toolchain/bin/../include/c++/v1/cwchar:128:9: error: no member named 'vswscanf' in the global namespace
using ::vswscanf;
      ~~^
/tmp/android-toolchain/bin/../include/c++/v1/cwchar:138:9: error: no member named 'wcstof' in the global namespace
using ::wcstof;
      ~~^

@DanAlbert @matiwinnetou @aschrijver any ideas 🤔 ?

PS: might be the same problem as in https://github.com/android-ndk/ndk/issues/452

[DanAlbert]

You're missing the libandroid_support headers. I'd recommend using the cmake toolchain file that's in the NDK at $NDK/build/cmake/android.toolchain.cmake.

libc++ as the stdlib (this seems to be recommended for the newer NDK versions)

Starting with the not yet released r16, yes, but if you need a full C++11 (or newer) STL then it's your only option.

[matiwinnetou]

@drywolf I wish I could help, this is too much outside of my area of expertise. Not only I don't have extensive c++ experience delicately saying but also no Android experience.

[aschrijver]

@drywolf same here, though I am learning a lot. I have updated https://github.com/nodejs/node/issues/14783 with latest findings, and I can do some test builds this weekend.

[drywolf]

You're missing the libandroid_support headers.

@DanAlbert Thanks for the hint, I already dug through the mentioned issue to see that this is the problem. What I can not figure out though is how to correctly include them. I am using a standalone toolchain as described by the NDK docs to build Node.js and now also the j2v8 lib. (the Node.js build already finished ok with that)

The r16 NDK I downloaded from the nightly builds (4280707), as mentioned here. And from that I created a standalone toolchain:

RUN $NDK/build/tools/make_standalone_toolchain.py \
    --arch x86 --api 17 --stl=libc++ --install-dir /tmp/android-toolchain

My own CMake toolchain file looks like this:

set(CMAKE_SYSTEM_NAME Android)
set(CMAKE_SYSTEM_VERSION 17) # API level

set(CMAKE_ANDROID_ARCH x86)
set(CMAKE_ANDROID_ARCH_ABI x86)
set(CMAKE_ANDROID_STANDALONE_TOOLCHAIN /tmp/android-toolchain)

# set(CMAKE_ANDROID_STL_TYPE c++_shared)
set(CMAKE_ANDROID_STL_TYPE c++_static)

set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -stdlib=libc++ -std=c++11 -fPIC")

When I now point CMake to use the android.toolchain.cmake file that is in the NDK directory (not the generated toolchain directory that I currently use) then CMake tries to locate the compiler binaries also in the NDK directory (among maybe also some other things)

-- Android: Targeting API '14' with architecture 'arm', ABI 'armeabi-v7a', and processor 'armv7-a'
-- Android: Selected Clang toolchain 'arm-linux-androideabi-clang' with GCC toolchain 'arm-linux-androideabi-4.9'
CMake Error at CMakeLists.txt:16 (project):
  The CMAKE_C_COMPILER:

    /temp/docker/android/android-ndk-r16-beta1-canary/toolchains//prebuilt/linux-x86_64/bin/clang

  is not a full path to an existing compiler tool.

(manually redirecting CMAKE_C_COMPILER & CXX compiler back to the standalone paths has no effect)

Also the first two lines about API 14 and armeabi-v7a seem entirely alien to me, because I am targeting API 17 / x86 with my build.

@DanAlbert I would not expect to point back to the NDK resources after I have run make_standalone_toolchain.py ... but if I really have to use the cmake toolchain file from the NDK directory, then is there something else that I need to set to make it use the right environment ? (API 17 and x86 in my case) ... I already tried to set the usual CMake variables for that, but nothing changed.

Thanks

[drywolf]

I have now made it to a point where the android support headers seem to be included property (I took the relevant parts from the NDK cmake files), but now there is another error about the typedef for size_t missing:

In file included from /j2v8/jni/com_eclipsesource_v8_V8Impl.cpp:12:
In file included from /j2v8/node/deps/v8/include/libplatform/libplatform.h:9:
In file included from /j2v8/node/deps/v8/include/libplatform/v8-tracing.h:8:
In file included from /temp/docker/android/android-ndk-r16-beta1-canary/sources/cxx-stl/llvm-libc++/include/fstream:169:
In file included from /temp/docker/android/android-ndk-r16-beta1-canary/sources/cxx-stl/llvm-libc++/include/ostream:138:
In file included from /temp/docker/android/android-ndk-r16-beta1-canary/sources/cxx-stl/llvm-libc++/include/ios:215:
In file included from /temp/docker/android/android-ndk-r16-beta1-canary/sources/cxx-stl/llvm-libc++/include/iosfwd:90:
In file included from /temp/docker/android/android-ndk-r16-beta1-canary/sources/cxx-stl/llvm-libc++/include/wchar.h:119:
In file included from /temp/docker/android/android-ndk-r16-beta1-canary/sources/android/support/include/wchar.h:32:
In file included from /tmp/android-toolchain/sysroot/usr/include/wchar.h:32:
In file included from /temp/docker/android/android-ndk-r16-beta1-canary/sources/cxx-stl/llvm-libc++/include/stdio.h:108:
In file included from /temp/docker/android/android-ndk-r16-beta1-canary/sources/android/support/include/stdio.h:31:
In file included from /tmp/android-toolchain/sysroot/usr/include/stdio.h:42:
In file included from /tmp/android-toolchain/sysroot/usr/include/sys/types.h:39:
/tmp/android-toolchain/sysroot/usr/include/bits/pthread_types.h:38:3: error: unknown type name 'size_t'
  size_t stack_size;

[drywolf]

I have managed to sort this out and also some linker errors after that, meaning I got a native j2v8 binary using Node.js 8.x for the first time ... but now comes the interesting part to see if this native library was correctly compiled so it can be loaded by the J2V8 AAR 🤞

[drywolf]

Not quite yet, but I think I'm still on the right track:

D/dalvikvm( 2306): Trying to load lib /data/app-lib/com.eclipsesource.v8.test-2/libj2v8.so 0xb1f707a0
E/dalvikvm( 2306): dlopen("/data/app-lib/com.eclipsesource.v8.test-2/libj2v8.so") failed: dlopen failed: cannot locate symbol "htons" referenced by "libj2v8.so"...
I/TestRunner( 2306): failed: testGetBooleanBiggerArray(com.eclipsesource.v8.V8ArrayTest)

@DanAlbert any idea about this one ? Where should this function come from when linking with the NDK ?

[DanAlbert]

Our toolchain file is not meant to work alongside a standalone toolchain. It's supposed to be used directly. Standalone toolchains are intended for interfacing with arbitrary build systems that are difficult to use with the NDK (autoconf, mostly). We support CMake, and that should Just Work (aside from any possible source compatibility issues with Android).

Can you share your build script? Just following along here it sounds like you're headed down the wrong track and having to put in a lot of effort just to handle the NDK. That shouldn't be needed for a CMake project.

E/dalvikvm( 2306): dlopen("/data/app-lib/com.eclipsesource.v8.test-2/libj2v8.so") failed: dlopen failed: cannot locate symbol "htons" referenced by "libj2v8.so"...

https://android.googlesource.com/platform/bionic/+/master/libc/libc.map.txt

htons wasn't in bionic (not as a real symbol, anyway, it may have been an inline because for some reason bionic was full of inlines prior to L) until L. If you have a result to this symbol from the build you were targeting at least L, but since that's an error from dalvik you're running on K at the latest. https://android.googlesource.com/platform/ndk/+/master/docs/user/common_problems.md#target-api-set-higher-than-device-api

[drywolf]

I pushed my progress to an experimental branch, with the following additions for building with Node 8.x and the r16 NDK beta:

• creating the standalone-toolchain from the NDK
• the CMake toolchain file
• build-script that compiles the J2V8 shared native library (using the CMake toolchain file from above)

The htons is used by Node.js, which is statically linked into the j2v8 shared library.

If you have a result to this symbol from the build you were targeting at least L, but since that's an error from dalvik you're running on K at the latest.

I think I get what you are saying there, but could you give me a hint how I could find out if that is the case. When I look at the build-scripts & configurations that I am using I can't see any origin for such a problem (mainly I'm looking at the API 17 level, which is below the platform level that I am creating the emulator from (android-19). Maybe I'm getting it wrong, but I thought I just had to compare the two numbers to know if code is going to work or not.

@DanAlbert Thanks for helping. Up until now I could figure out most things myself. But for this specific error I might be out of ideas.

[drywolf]

Now I am trying to just use the NDK + toolchain.cmake file (based on your suggestion from above & this blog post)

When I do that I get the following output, which is similar to what I already had seen during my previous attempts, but by setting the right variables at the CMake CLI at least now the platform and api-level seem to be alright.

SHELL building android@x86 => j2v8cmake
-- Android: Targeting API '17' with architecture 'x86', ABI 'x86', and processor 'i686'
-- Android: Selected Clang toolchain 'x86-clang' with GCC toolchain 'x86-4.9'
CMake Error at CMakeLists.txt:16 (project):
  The CMAKE_C_COMPILER:

    /temp/docker/android/android-ndk-r16-beta1-canary/toolchains//prebuilt/linux-x86_64/bin/clang

  is not a full path to an existing compiler tool.

What is strange about this error though (and I saw this before, but I thought it was just a irrelevant glitch in the path) is the double forward-slash between "toolchains" and "prebuilt". I checked the directories & files in the NDK and it looks like the actually expected right path should be: /temp/docker/android/android-ndk-r16-beta1-canary/toolchains/llvm/prebuilt/linux-x86_64

The llvm is apparently missing, now I am trying to figure out if there is another CMake Android/NDK parameter that I am missing.

PS: the point of the problem might be along these lines of the CMake scripts: https://github.com/Kitware/CMake/blob/0e9634d2c90fd748774f9238219cb1661550f233/Modules/Platform/Android/Determine-Compiler-NDK.cmake#L230-L232

[drywolf]

@DanAlbert even if I manually correct this in CMake's installed script files and set "llvm" manually, I just return back to the point where I have to deal with missing include directories, exactly the same that I had to deal with from five posts ago. So the NDK toolchain file does really not seem to work any better than writing my own at this moment (quite the opposite actually). 🙁

[DanAlbert]

Which CMake version are you using? If this isn't dead simple to do, that's a bug. I'll take a look on Monday if you can point me to some build instructions.

[drywolf]

I went back to the problem about htons not being defined and found the following code in Node.js that when active just inlines its own implementations for those functions. It is only used for WIN32 usually, but as an attempt to fix the problem I also included it for the Android build.

After that, the linking problem about htons when loading the j2v8.so went away. But there was another function missing getservbyport_r, for this one Node.js already had a config-flag that I could just turn off and then this function will not be used.

@matiwinnetou @aschrijver @irbull

And now with those two issues fixed I was finally able to run a first unit-test class of J2V8 sucessfully with Node.js 8.4.0 ...

Now I will run the full unit-test suite and see how it turns out (this will take some time, since running the ~2.5k tests in the emulator can be pretty slow), but I am already 300 tests in and so far everything ran just fine. 🎉 😄 🎉

@DanAlbert The build is using CMake: 3.8.1 on Ubuntu 17.04 (it's running in a docker container) I can give you some details how to set everything up and reproduce this tomorrow.

Now I need some 😴

[matiwinnetou]

@drywolf So you had success with 8.4.0 but not 8.2.1 with android? 8.4.0 already uses V8: 6.0 and I had some issues to compile this with Linux or OSX, this is the reason why I decided to try 8.2.1 for the moment. Were you successful to compile and build j2v8 against windows, osx and linux using 8.4.0 or you didn't try?

[drywolf]

That's right @matiwinnetou I switched to 8.4.0 for Android because 8.2.1 seemed very flaky to try and compile on Android (especially this problem and related issues about mkpeephole). I did not try for the other platforms yet with 8.4.0 ... but I think I could give it a try today after work maybe and I will let you know about the results.

[matiwinnetou]

@drywolf any news on NodeJS 8.3.0 building with osx and linux?

[drywolf]

@matiwinnetou I put a table with the current results in the first post just now.

I got 8.4.0 to compile on pretty much all platforms ... but something seems to be causing trouble on the native side for the Linux & MacOS platforms ... which leads to crashes while running the unit tests. I do not have much time to investigate much deeper until the weekend.

[drywolf]

The problems running the tests on Linux & MacOS seem to all have the same origin, which I was not able to figure out yet. @matiwinnetou @irbull Have you done debugging of the J2V8 native code on Linux (gdb?) ... can you give me any hints / tips how to go about debugging the native code and which tools to use

[matiwinnetou]

@drywolf Sadly I never debugged with gdb sorry. So far it was not necessary, I was getting away with console.log...

[teaserbot]

@drywolf :

you 岩! :D

[ohm62]

@drywolf - from your matrix above, I understand you were able to build J2V8 with Node.js 8.4 on Windows. Care to share how you accomplished that?

Even after pulling latest J2V8 sources from master, as advised elsewhere, I run into the error The specified solution configuration "Release|X86" is invalid. trying to use option 9 of the interactive build:

Build log extract: `

Building the projects in this solution one at a time. To enable parallel build, please add the "/m" switch. Build started 11/15/2017 4:05:50 PM. Project "C:\Dev\J2V8\cmake.out\win32.x64\j2v8.sln" on node 1 (default targets). C:\Dev\J2V8\cmake.out\win32.x64\j2v8.sln.metaproj : error MSB4126: The specified solution configuration "Release|X86" is invalid. P lease specify a valid solution configuration using the Configuration and Platform properties (e.g. MSBuild.exe Solution.sln /p:Conf iguration=Debug /p:Platform="Any CPU") or leave those properties blank to use the default solution configuration. [C:\Dev\J2V8\cmak e.out\win32.x64\j2v8.sln] Done Building Project "C:\Dev\J2V8\cmake.out\win32.x64\j2v8.sln" (default targets) -- FAILED.

Build FAILED.

"C:\Dev\J2V8\cmake.out\win32.x64\j2v8.sln" (default target) (1) -> (ValidateSolutionConfiguration target) -> C:\Dev\J2V8\cmake.out\win32.x64\j2v8.sln.metaproj : error MSB4126: The specified solution configuration "Release|X86" is invalid. Please specify a valid solution configuration using the Configuration and Platform properties (e.g. MSBuild.exe Solution.sln /p:Co nfiguration=Debug /p:Platform="Any CPU") or leave those properties blank to use the default solution configuration. [C:\Dev\J2V8\cm ake.out\win32.x64\j2v8.sln]

0 Warning(s)
1 Error(s)

---

`

And BTW, the log produced suggests that this is still building against Node.js v7.4 :-((((( How do you get Node.js 8.4 instead? We need this for es6 support.

Thanks,

-- OHM.

[drywolf]

@hurol02 I think the most recent parts that I added to get node 8.4.x to compile are not yet available in the repo, since I didn't want to put it on unless I could figure out the crashes on linux (see above).

I will have another look over the course of the weekend and at least make the updated win32 build available under an experimental branch.

As for the log above, the error error MSB4126: The specified solution configuration "Release|X86" reads to me as if something is really messed up in the project files that cmake generated there. Especially since the rest of the log indicates that you are trying to run an x64 build, in which case cmake should not have generated any x86 targets for visual studio to build. The best idea might be to clean out the C:\Dev\J2V8\cmake.out directory and let cmake generate fresh project files. If the problem persists, please give some more details about your build environment. E.g. which version of visual studio / windows sdk are you using ?

PS: I just had a look at my fork, there is a branch already there that should contain the most essential commits to get 8.4.x running™ You could try and give it a spin, but this is all experimental until I can get back to it and iron out the problems discussed above :wink:

[ohm62]

@drywolf Your quick update on the situation of the win32 build with Node.js 8.4 is much appreciated. I will definitely give a try to the branch you pointed out, to exercise the build part, and will stay tuned for your analysis of the issues you observed on Linux.

VS is not available to me, so I am using Visual C++ build tools 2015 (MSBuild v14.0.25420.1) on Windows 7 64-bits... I also tried the VC++ build tools 2017, and started over with a fresh pull of the master branch from repo. to no avail.

FYI, I had also tried the 32-bit build with the exact same outcome (same error on solution configuration "Release|x86"). I think somehow it is looking for a match with "Release|x64" or "Release|x32" instead, intuited from the "solution configuration file" contents. I am not familiar with Visual Studio nor MSBuild, so I am guessing: x86 must be characteristic of the Intel processor architecture, say as opposed to ARM, rather than the word length, and something looks misplaced in the parametrization of MSBuild, that perhaps passed the processor architecture keyword in place of its word length. I briefly tried to find my way through the proprietary Python build to confirm the hypothesis and perhaps fix it, but it is somewhat involved and - under pressure to find an alternate solution for my project needs - I could not spare the time to go deep, not knowing if that could be just the first of a possibly long series of issues.

[ohm62]

Windows x86 64-bits build from that experimental branch failed as well.

BTW, for those who might want to try that as well, the build config defaults to using NodeJS 7.4.0, even in that branch. To get it to use 8.4.0 instead, you need to edit the file build_system\build_settings.py and change the NodeJS settings there as follows:

#-----------------------------------------------------------------------
# Node.js settings
#-----------------------------------------------------------------------
# [user-setting] you can change this if you plan to use a different Node.js version for the J2V8 build
NODE_VERSION_MAJOR, NODE_VERSION_MINOR, NODE_VERSION_PATCH = 8, 4, 0

[lsmobile]

Hello, @drywolf, @matiwinnetou and other experts!

How did you build J2V8 on Node.js 8x? I experimented with Windows and Ubuntu on different versions of Node.js from 7x to 9x and always rested on a lot of compilation errors. For example, this:

>build -t win32 -a x64 -ne
Checking Node.js builtins integration consistency...
ERROR: J2V8 linking builtins code does not match Node.js builtin modules, check jni/com_eclipsesource_v8_V8Impl.cpp
        J2V8 definition is missing node-modules: ['inspector', 'http2', 'performance', 'serdes']

What can be done? Thank you in advance!

[matiwinnetou]

I needed a branch, I compiled from my branch: https://github.com/matiwinnetou/J2V8/tree/nodejs8

I can also give you compiled versions for Linux and OSX if you trust my binaries :)

[matiwinnetou]

-rw-r--r--    1 root     root       8613258 Jul 29 13:55 j2v8_linux_x86_64-nodejs-7-4-0-SNAPSHOT.jar
-rw-r--r--    1 root     root       7554160 Aug  5 21:34 j2v8_linux_x86_64-nodejs-7.9.0-SNAPSHOT.jar
-rw-r--r--    1 root     root       7673030 Aug 16 19:12 j2v8_linux_x86_64-nodejs-8-2-1-SNAPSHOT.jar
-rw-r--r--    1 root     root       6608506 Jul 29 13:50 j2v8_macos_x86_64-nodejs-7-4-0-SNAPSHOT.jar
-rw-r--r--    1 root     root       6819821 Aug  5 21:31 j2v8_macos_x86_64-nodejs-7.9.0-SNAPSHOT.jar
-rw-r--r--    1 root     root       7123678 Aug 16 18:48 j2v8_macos_x86_64-nodejs-8.2.1-SNAPSHOT.jar

[matiwinnetou]

I don't think anything above 8.2.x will work easily without more dramatic J2V8 changes

[lsmobile]

Hello @matiwinnetou and thanks for the reply,

could you put here a link to your binaries for Linux?

Thank you in advance!

[matiwinnetou]

sure, a bit of patience

[matiwinnetou]

I can expose this on my private web server this evening (late evening) or mail to you simply two jar files with latest 8.x NodeJS. This could really fast then.

[lsmobile]

@matiwinnetou (https://github.com/matiwinnetou/J2V8/tree/nodejs8)

~/git/J2V8 $ bash buildAll.sh
buildAll.sh: line 40: docker: command not found
buildAll.sh: line 41: docker: command not found
buildAll.sh: line 42: docker: command not found
tar (child): node.out-7_4_0.tar.gz: Cannot open: No such file or directory
tar (child): Error is not recoverable: exiting now
tar: Child returned status 2
tar: Error is not recoverable: exiting now

[matiwinnetou]

It works, but it assumes certain steps, like downloading NodeJS (prepare script), having docker available...

[lsmobile]

Without the Docker will not build at all?

[lsmobile]

@matiwinnetou I sent an email about binaries for Linux

[matiwinnetou]

I sent you an email with j2v8.tar, let me know if you got this.

[lsmobile]

@matiwinnetou , the result:

java.lang.IllegalStateException: J2V8 native library not loaded (j2v8-linuxmint-linux-x86_64/j2v8-linuxmint-linux-x86_64)
    at com.eclipsesource.v8.V8.checkNativeLibraryLoaded(V8.java:257)
    at com.eclipsesource.v8.V8.createV8Runtime(V8.java:153)
    at com.eclipsesource.v8.V8.createV8Runtime(V8.java:129)
    at com.eclipsesource.v8.NodeJS.createNodeJS(NodeJS.java:84)
    at com.eclipsesource.v8.NodeJS.createNodeJS(NodeJS.java:48)

[matiwinnetou]

Please study LibraryLoader.java a bit, you will have to change the name of *.so file in your jar file to match your distribution. Sadly you have some very weird names. @drywolf did some work there but maybe the matching algorithm does not always work.

[matiwinnetou]

    private static String computeLibraryFullName() {
        return "lib" + computeLibraryShortName() + "." + getOSFileExtension();
    }

Alternatively you have an issue with where the *.so file is stored, you can specify working dir yourself but normally it is java temp directory.

[p-bakker]

Hi,

Eager to get my hands on a J2V8 jar that uses Node 7 or 8.

As far as I can tell, none are available yet, as kinks in the cross platform built process are still being worked out?

Or are there downloads available somewhere for testing purposes?

Any timeline on a official release using a newer version of Node?

Paul

[ankurchauhan]

Hi everyone,

Just wanted to check if there has been any release of J2v8 which supports nodeJs version 6.9.+ , I tried using J2v8 4.6.0 (for windows OS) and it creates a NodeJs env of 5.9.1 only.

Regards, Ankur

[ChronosXYZ]

Oh, who has pre-compiled J2V8 with Node.js 8.0.0 and higher for Android ARMv7? I have already lost a week due to the fact that I can not compile it. I beg you, if anyone has it, post it or send it to me. Thank you in advance.

[thomashoef]

@irbull would you be adding a v8 update / nodejs update to support async/await? Thanks for any update.

[JessHolle]

@irbull First off, thanks for the great efforts to get fat/64-bit support in place, etc.

With those issues resolved, however, I believe this is the top J2V8 issue, i.e. getting to a more recent V8.

[clearw5]

Oh, who has pre-compiled J2V8 with Node.js 8.0.0 and higher for Android ARMv7? I have already lost a week due to the fact that I can not compile it. I beg you, if anyone has it, post it or send it to me. Thank you in advance.

+1

[yuchonghua]

When will there be a new maven package release? /ping @drywolf

[mkshiblu]

When we will be able to see the artifacts with NodeJs version 10+?