NodeJS binding against node-v69?

[dsteinman]

After upgrading my version of NodeJS to v10.15.2 I can no longer compile DeepSpeech because there's no v69 version of the binding. I would rather try to update DeepSpeech for v69 than to try downgrading again. I don't exactly know how to do this, but this is where I'm at:

[0] Note that the development build is not optimized.
[0] To create a production build, use npm run build.
[0] 
[1] App threw an error during load
[1] Error: The module 'electron-app/node_modules/deepspeech/lib/binding/v0.4.1/darwin-x64/electron-v4.1/deepspeech.node'
[1] was compiled against a different Node.js version using
[1] NODE_MODULE_VERSION 67. This version of Node.js requires
[1] NODE_MODULE_VERSION 69. Please try re-compiling or re-installing
[1] the module (for instance, using `npm rebuild` or `npm install`).
[1]     at process.module.(anonymous function) [as dlopen] (ELECTRON_ASAR.js:160:31)
[1]     at Object.Module._extensions..node (internal/modules/cjs/loader.js:722:18)
[1]     at Object.module.(anonymous function) [as .node] (ELECTRON_ASAR.js:160:31)
[1]     at Module.load (internal/modules/cjs/loader.js:602:32)
[1]     at tryModuleLoad (internal/modules/cjs/loader.js:541:12)
[1]     at Function.Module._load (internal/modules/cjs/loader.js:533:3)
[1]     at Module.require (internal/modules/cjs/loader.js:640:17)
[1]     at require (internal/modules/cjs/helpers.js:20:18)
[1]     at Object.<anonymous> (electron-app/node_modules/deepspeech/index.js:5:17)
[1]     at Object.<anonymous> (electron-app/node_modules/deepspeech/index.js:59:3)

FYI there's an electron-v4.1 directory there because I'm using ElectronJS which requires a softlink from:

deepspeech/lib/binding/v0.4.1/darwin-x64/electron-v4.1

To:

deepspeech/lib/binding/v0.4.1/darwin-x64/node-v69

But there is no node-v69 there are only these versions:

node-v46/
node-v48/
node-v57/
node-v64/         
node-v47/
node-v51/
node-v59/
node-v67/

So I need to know how to add a node-v69 entry I also tried upgrade to NodeJS v11.13.0 with the same problem, it also wants node-v69.

I looked around in the DeepSpeech repo, and it looks like there's just one file that might need to be updated:

taskcluster/.shared.yml

    prep_10: 'nvm install 10.12.0 && nvm use 10.12.0'
    prep_11: 'nvm install 11.0.0 && nvm use 11.0.0'

So I'm guessing 2 additional lines should be added:

prep_12: 'nvm install 10.15.2 && nvm use 10.15.0'
prep_13: 'nvm install 11.13.0 && nvm use 11.13.0'

Or maybe re-order the "prep" lines to match?

[lissyx]

There is no 69 here: https://nodejs.org/en/download/releases/

[dsteinman]

Is it possible that list is wrong or out of date?

How else could NPM could be giving me the error "This version of Node.js requires [1] NODE_MODULE_VERSION 69" if v69 does not exist?

[lissyx]

How else could NPM could be giving me the error "This version of Node.js requires [1] NODE_MODULE_VERSION 69" if v69 does not exist?

I can't do divination ... But you mention electron. Maybe they have more recent NODE_MODULE_VERSION ?

[lissyx]

So I'm guessing 2 additional lines should be added:

prep_12: 'nvm install 10.15.2 && nvm use 10.15.0'
prep_13: 'nvm install 11.13.0 && nvm use 11.13.0'

Those are fine, the NODE_MODULE_VERSION is the same as the ones we currently have.

[lissyx]

@dsteinman You can try to just rebuild, there's the make call here, you might not need everything, basically just the proper node verison: https://github.com/mozilla/DeepSpeech/blob/master/tc-tests-utils.sh#L1105-L1110

Followed by that other make call: https://github.com/mozilla/DeepSpeech/blob/master/tc-tests-utils.sh#L1116

You should download latest stable native_client.tar.xz and create bazel-bin/native_client/ directory where you place libdeepspeech. Then in both of the above make specify TFDIR=with the path containing yourbazel-bin/`.

I can't promise that node-gyp and node-pre-gyp will be happy about this v69 since they also have some mapping, but maybe you can start from here and get there.

[lissyx]

@dsteinman Here: https://github.com/mapbox/node-pre-gyp/blob/master/lib/util/abi_crosswalk.json there's no v69 either, but maybe you can add it manually and hope it will work, except I have no idea about the matching v8, and there might be other sites to update.

[dsteinman]

Okay it didn't occur to me that Electron could actually be ahead of NodeJS in terms of these module numbers. I did a google search and I did find some hits on this same issue.

If there's no way to update Deepspeech to 69 right now I'll just downgrade my version of Electron and find a version which ships with v67.

[dsteinman]

Bingo, they bumped to v69 in Electron 4.0.4:

https://electronjs.org/releases/stable?page=2#release-notes-for-v404

[lissyx]

If there's no way to update Deepspeech to 69 right now I'll just downgrade my version of Electron and find a version which ships with v67.

Maybe worth you give a try to what I suggested, otherwise we have to wait for next NodeJS release.

[reuben]

From the linked issue there it seems like Electron is moving to their own ABI version, separate from Node.JS, and next Node releases won't fix it? Or am I reading it incorrectly?

[dsteinman]

@reuben perhaps, it looks like some other way to do this linking may be required for Electron support.

Downgrading Electron has also not been successful. Both Electron v4.0.3 and v4.0.0 want to link against node-v69 for some reason.

And I also tried Electron 3.1.8, which wants node-v64, but then that fails for a different reason:

[0] Starting the development server...
[0] 
[1] Debugger listening on ws://127.0.0.1:5858/74a3b116-e716-465c-bc61-91430f2ac313
[1] For help, see: https://nodejs.org/en/docs/inspector
[1] dyld: lazy symbol binding failed: Symbol not found: __ZN2v816FunctionTemplate3NewEPNS_7IsolateEPFvRKNS_20FunctionCallbackInfoINS_5ValueEEEENS_5LocalIS4_EENSA_INS_9SignatureEEEiNS_19ConstructorBehaviorENS_14SideEffectTypeE
[1]   Referenced from: electron-app/node_modules/deepspeech/lib/binding/v0.4.1/darwin-x64/node-v64/deepspeech.node
[1]   Expected in: flat namespace
[1] 
[1] dyld: Symbol not found: __ZN2v816FunctionTemplate3NewEPNS_7IsolateEPFvRKNS_20FunctionCallbackInfoINS_5ValueEEEENS_5LocalIS4_EENSA_INS_9SignatureEEEiNS_19ConstructorBehaviorENS_14SideEffectTypeE
[1]   Referenced from: electron-app/node_modules/deepspeech/lib/binding/v0.4.1/darwin-x64/node-v64/deepspeech.node
[1]   Expected in: flat namespace

I did previously have this working with Electron 2.0.2 and node-v57 but these are too old and have vulnerabilities.

I haven't tried to compile DeepSpeech manually, but at this point I don't think that's going to matter unless I know how to link the deepspeech.node in electron.

[lissyx]

And I also tried Electron 3.1.8, which wants node-v64, but then that fails for a different reason:

On the bug you linked it seemed they followed different ABI, that might explain it

I haven't tried to compile DeepSpeech manually, but at this point I don't think that's going to matter unless I know how to link the deepspeech.node in electron.

No need to rebuild libdeepspeech.so, and I already gave you hints on how you might want to try for deepspeech.node with v69. It's also possible swig will not be a good friend here

[lissyx]

@dsteinman https://electronjs.org/releases/stable#release-notes-for-v410 Can you try and find more informations about that: Electron 4.1.0 was released to work around issues users were experiencing with node-pre-gyp based native modules and our ABI number in Electron >= 4.0.4. ?

[lissyx]

@dsteinman mapbox/node-pre-gyp#437 (comment) According to that comment, then we could pass --runtime=electron to node-pre-gyp with the suggestions from above. Hoping that the SWIG-generated bindings are good as well ...

[dsteinman]

@lissyx I appreciate the help, yes I think indeed adding the right node-gyp variables in the right place within the DeepSpeech build tools could do the trick, I found this as well:

https://electronjs.org/docs/tutorial/using-native-node-modules

Usually those modules work fine under Electron, but sometimes when Electron uses a newer version of V8 than Node, and there are ABI changes, bad things may happen. So in general it is recommended to always build native modules from source code.

[lissyx]

@dsteinman So I don't have an electron runtime but: native_client/javascript/lib/binding/v0.5.0-alpha.5/linux-x64/electron-v4.1/deepspeech.node

diff --git a/native_client/javascript/Makefile b/native_client/javascript/Makefile
index 54e39d9..87ad53e 100644
--- a/native_client/javascript/Makefile
+++ b/native_client/javascript/Makefile
@@ -36,13 +36,13 @@ configure: deepspeech_wrap.cxx package.json
        $(NODE_BUILD_TOOL) configure $(NODE_BUILD_VERBOSE)
 
 build: configure deepspeech_wrap.cxx
-       AS=$(AS) CC=$(CC) CXX=$(CXX) LD=$(LD) CFLAGS="$(CFLAGS)" CXXFLAGS="$(CXXFLAGS)" LDFLAGS="$(RPATH_NODEJS) $(LDFLAGS)" LIBS=$(LIBS) $(NODE_BUILD_TOOL) $(NODE_PLATFORM_TARGET) $(NODE_ABI_TARGET) rebuild $(NODE_BUILD_VERBOSE)
+       AS=$(AS) CC=$(CC) CXX=$(CXX) LD=$(LD) CFLAGS="$(CFLAGS)" CXXFLAGS="$(CXXFLAGS)" LDFLAGS="$(RPATH_NODEJS) $(LDFLAGS)" LIBS=$(LIBS) $(NODE_BUILD_TOOL) $(NODE_PLATFORM_TARGET) $(NODE_RUNTIME) $(NODE_ABI_TARGET) rebuild $(NODE_BUILD_VERBOSE)
 
 copy-deps: build
        $(call copy_missing_libs,lib/binding/*/*/*/deepspeech.node,lib/binding/*/*/)
 
 node-wrapper: copy-deps build
-       $(NODE_BUILD_TOOL) $(NODE_PLATFORM_TARGET) $(NODE_ABI_TARGET) package $(NODE_BUILD_VERBOSE)
+       $(NODE_BUILD_TOOL) $(NODE_PLATFORM_TARGET) $(NODE_RUNTIME) $(NODE_ABI_TARGET) package $(NODE_BUILD_VERBOSE)
 
 npm-pack: clean package.json README.md index.js
        npm install node-pre-gyp@0.12.x

and then:

$ PATH=$HOME/node_modules/.bin/:$PATH make -C native_client/javascript/ TFDIR=/home/alex/tmp/deepspeech/0.5.0a5 NODE_RUNTIME=--runtime=electron NODE_ABI_TARGET=--target=4.1.0 clean node-wrapper clean npm-pack

[lissyx]

At runtime, though:

$  node_modules/electron/dist/electron node_modules/deepspeech/index.js 
App threw an error during load
Error: The module '/home/alex/tmp/deepspeech/0.5.0a5/node_modules/deepspeech/lib/binding/v0.5.0-alpha.5/linux-x64/electron-v4.1/deepspeech.node'
was compiled against a different Node.js version using
NODE_MODULE_VERSION 46. This version of Node.js requires
NODE_MODULE_VERSION 69. Please try re-compiling or re-installing

[lissyx]

Ok @dsteinman I got it, one also need to give proper download URL so in the previous patch you need to add a $(NODE_DIST_URL) and add that to the make call: NODE_DIST_URL=--disturl=https://atom.io/download/electron

Then I don't have any error but I'm facing a big issue: I don't know how to test that. We can likely quickly add build for many versions of ElecronJS, but so far you should not expect "support". If you can send PR for a test, it would be helpful.

[lissyx]

@dsteinman So that https://queue.taskcluster.net/v1/task/L5TQAdXJRaa_evk39cV4jg/runs/0/artifacts/public/deepspeech-0.5.0-alpha.5.tgz should bundle from ElectronJS v1.6 to v4.1

[lissyx]

Seems to work here:

alex@portable-alex:~/tmp/deepspeech/0.5.0a5$  node_modules/electron/dist/electron node_modules/deepspeech/client.js --version
TensorFlow: v1.13.1-10-g3e0cc53
DeepSpeech: v0.5.0-alpha.5-5-g8fa3551
Runtime: Electron
alex@portable-alex:~/tmp/deepspeech/0.5.0a5$ node_modules/electron/dist/electron node_modules/deepspeech/client.js --model ../output_graph_test.pbmm --audio ../test-alex.en.wav --alphabet ../models/alphabet.txt 
Loading model from file ../output_graph_test.pbmm
TensorFlow: v1.13.1-10-g3e0cc53
DeepSpeech: v0.5.0-alpha.5-5-g8fa3551
2019-04-10 12:09:48.412286: I tensorflow/core/platform/cpu_feature_guard.cc:141] Your CPU supports instructions that this TensorFlow binary was not compiled to use: AVX2 FMA
2019-04-10 12:09:48.416918: E tensorflow/core/framework/op_kernel.cc:1325] OpKernel ('op: "UnwrapDatasetVariant" device_type: "CPU"') for unknown op: UnwrapDatasetVariant
2019-04-10 12:09:48.416941: E tensorflow/core/framework/op_kernel.cc:1325] OpKernel ('op: "WrapDatasetVariant" device_type: "GPU" host_memory_arg: "input_handle" host_memory_arg: "output_handle"') for unknown op: WrapDatasetVariant
2019-04-10 12:09:48.416950: E tensorflow/core/framework/op_kernel.cc:1325] OpKernel ('op: "WrapDatasetVariant" device_type: "CPU"') for unknown op: WrapDatasetVariant
2019-04-10 12:09:48.416997: E tensorflow/core/framework/op_kernel.cc:1325] OpKernel ('op: "UnwrapDatasetVariant" device_type: "GPU" host_memory_arg: "input_handle" host_memory_arg: "output_handle"') for unknown op: UnwrapDatasetVariant
Loaded model in 0.006207s.
Running inference.
she ha h h h h harea e eaha e h h h ha
Inference took 0.3959s for 3.625s audio file.
process.versions.electron=4.1.1

[lissyx]

On TC: https://tools.taskcluster.net/groups/DLv_Y-JgQKmKm0sl4pTJ7A/tasks/DLv_Y-JgQKmKm0sl4pTJ7A/runs/0

[dsteinman]

@lissyx Terrific! Unfortunately I don't have a quick way to test this out yet because I don't have DeepSpeech and TensorFlow compiling locally but I'll probably work on it today.

[lissyx]

@lissyx Terrific! Unfortunately I don't have a quick way to test this out yet because I don't have DeepSpeech and TensorFlow compiling locally but I'll probably work on it today.

Well in a few minutes you should be able to see a working package at https://tools.taskcluster.net/groups/OLINF0wXR8uzo0aF8cirPQ/tasks/bVVTsw2oTsuRgKiBdnbWaA/runs/0/artifacts

I still have a few changes to push to add more test coverage, but assuming this will go smoothly on v3.8, v4.0 for linux/macOS/windows, we should be able to merge today

[dsteinman]

Great work @lissyx I downloaded that package and yeah it looks like it's working so far. I have some more code to load in but this is going to be really awesome. If you're curious what I'm doing with it, I'm using an electron app so I can connect DeepSpeech to web pages (client-side) through a web browser extension. Not sure if anyone has thought to do this but so far it's working reasonably well.

[dsteinman]

Will a new set of 0.5-alpha model files be required? The files in deepspeech-0.4.1-models.tar.gz is giving me this error:

TensorFlow: v1.13.1-10-g3e0cc5374d
DeepSpeech: v0.5.0-alpha.4-92-gdcee783
2019-04-10 12:21:04.963447: I tensorflow/core/platform/cpu_feature_guard.cc:141] Your CPU supports instructions that this TensorFlow binary was not compiled to use: AVX2 FMA
2019-04-10 12:21:04.975890: E tensorflow/core/framework/op_kernel.cc:1325] OpKernel ('op: "UnwrapDatasetVariant" device_type: "GPU" host_memory_arg: "input_handle" host_memory_arg: "output_handle"') for unknown op: UnwrapDatasetVariant
2019-04-10 12:21:04.975922: E tensorflow/core/framework/op_kernel.cc:1325] OpKernel ('op: "UnwrapDatasetVariant" device_type: "CPU"') for unknown op: UnwrapDatasetVariant
2019-04-10 12:21:04.975934: E tensorflow/core/framework/op_kernel.cc:1325] OpKernel ('op: "WrapDatasetVariant" device_type: "GPU" host_memory_arg: "input_handle" host_memory_arg: "output_handle"') for unknown op: WrapDatasetVariant
2019-04-10 12:21:04.975944: E tensorflow/core/framework/op_kernel.cc:1325] OpKernel ('op: "WrapDatasetVariant" device_type: "CPU"') for unknown op: WrapDatasetVariant
Specified model file version (0) is incompatible with minimum version supported by this client (1). See https://github.com/mozilla/DeepSpeech/#model-compatibility for more information

/deepspeech-node/index.js:28
        throw "CreateModel failed with error code " + status;
        ^
CreateModel failed with error code 8195

[reuben]

We don't release model files with alpha releases, but yes, new models will be required. You may be able to re-export the 0.4.1 models with the latest code to get a working model, but we haven't tried it yet and don't know how hard it would be.

[dsteinman]

No problem, I'm not quite confident enough that I'll be able to figure it out on my own so I don't mind waiting. But is there any ETA for this new 0.5 version?

[lissyx]

But is there any ETA for this new 0.5 version?

I think biggest blocker is on my end with the exposure of metadata struct to bindings, JS and Python have a working solution but not yet Java.

[lissyx]

But is there any ETA for this new 0.5 version?

Not yet

[dsteinman]

Okay I'm looking forward to it, and will try it out as soon as it's released. Thanks for all the help.

[lock]

This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.