www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - how do i fix this node_dlang error?

reply Jack <jckj33 gmail.com> writes:
I'm trying to use the node_dlang pakckage but the code example 
from [this 
repo](https://github.com/NotSpooky/node_dlang/tree/v0.4.11/examples) isn't
working

the command ```dub build``` is fine but ```node example.js``` 
retuns an error saying the module.node is not a valid win32 
application. How do I fix this?

[1]: https://github.com/NotSpooky/node_dlang/tree/v0.4.11/examples
Jun 05
next sibling parent reply Mike Parker <aldacron gmail.com> writes:
On Sunday, 6 June 2021 at 04:25:39 UTC, Jack wrote:
 I'm trying to use the node_dlang pakckage but the code example 
 from [this 
 repo](https://github.com/NotSpooky/node_dlang/tree/v0.4.11/examples) isn't
working

 the command ```dub build``` is fine but ```node example.js``` 
 retuns an error saying the module.node is not a valid win32 
 application. How do I fix this?

 [1]: 
 https://github.com/NotSpooky/node_dlang/tree/v0.4.11/examples
Looking at node_dlang's dub.json, it's building a DLL then renaming it to module.node. The JS script then causes node to load the DLL. So I expect this error may be related to a 32-bit vs. 64-bit issue. I assume you are on 64-bit Windows, in which case recent versions of dub compile as 64-bit by default. So if that's the case, and your installation of node is 32-bit, you would see this error. Ditto when you're loading a 32-bit DLL in a 64-bit process.
Jun 05
next sibling parent Jack <jckj33 gmail.com> writes:
On Sunday, 6 June 2021 at 06:10:18 UTC, Mike Parker wrote:
 On Sunday, 6 June 2021 at 04:25:39 UTC, Jack wrote:
 I'm trying to use the node_dlang pakckage but the code example 
 from [this 
 repo](https://github.com/NotSpooky/node_dlang/tree/v0.4.11/examples) isn't
working

 the command ```dub build``` is fine but ```node example.js``` 
 retuns an error saying the module.node is not a valid win32 
 application. How do I fix this?

 [1]: 
 https://github.com/NotSpooky/node_dlang/tree/v0.4.11/examples
Looking at node_dlang's dub.json, it's building a DLL then renaming it to module.node. The JS script then causes node to load the DLL. So I expect this error may be related to a 32-bit vs. 64-bit issue. I assume you are on 64-bit Windows, in which case recent versions of dub compile as 64-bit by default. So if that's the case, and your installation of node is 32-bit, you would see this error. Ditto when you're loading a 32-bit DLL in a 64-bit process.
that's right, I was on 64bit system and node was 32bit installation (I didn't even realize I installed the 32bit instead of 64bit). I just installed node 64bit version, that fixed, thanks!
Jun 06
prev sibling parent reply Jack <jckj33 gmail.com> writes:
On Sunday, 6 June 2021 at 06:10:18 UTC, Mike Parker wrote:
 On Sunday, 6 June 2021 at 04:25:39 UTC, Jack wrote:
 I'm trying to use the node_dlang pakckage but the code example 
 from [this 
 repo](https://github.com/NotSpooky/node_dlang/tree/v0.4.11/examples) isn't
working

 the command ```dub build``` is fine but ```node example.js``` 
 retuns an error saying the module.node is not a valid win32 
 application. How do I fix this?

 [1]: 
 https://github.com/NotSpooky/node_dlang/tree/v0.4.11/examples
Looking at node_dlang's dub.json, it's building a DLL then renaming it to module.node. The JS script then causes node to load the DLL. So I expect this error may be related to a 32-bit vs. 64-bit issue. I assume you are on 64-bit Windows, in which case recent versions of dub compile as 64-bit by default. So if that's the case, and your installation of node is 32-bit, you would see this error. Ditto when you're loading a 32-bit DLL in a 64-bit process.
the npm was 32bit so the switch to 64bit worked then npm example.js ran file but electron requires a 32bit module, so I need to switch back to npm 32bit. Now, I can't build the example from node_dlang with --arch=x86, returns the error: command: ```$ dub --arch=x86``` output: ``` Performing "debug" build using C:\D\dmd2\windows\bin\dmd.exe for x86, x86_omf. node_dlang 0.4.11: building configuration "node_dlang_windows"... ..\..\AppData\Local\dub\packages\node_dlang-0.4.11\node_dlang\source\n de_dlang.d(137,11): Error: none of the overloads of `this` are callable using argument types `(string, string, ulong, Throwable)`, candidates are: C:\D\dmd2\windows\bin\..\..\src\druntime\import\object.d(2440,30): `object.Exception.this(string msg, string file = __FILE__, uint line = cast(uint)__LINE__, Throwable nextInChain = null)` C:\D\dmd2\windows\bin\..\..\src\druntime\import\object.d(2445,30): `object.Exception.this(string msg, Throwable nextInChain, string file = __FILE__, uint line = cast(uint)__LINE__)` C:\D\dmd2\windows\bin\dmd.exe failed with exit code 1. ```
Jun 06
parent reply Mike Parker <aldacron gmail.com> writes:
On Sunday, 6 June 2021 at 15:42:55 UTC, Jack wrote:
0.4.11\node_dlang\source\node_dlang.d(137,11): Error: none of the 
overloads of `this` are callable using argument types `(string, 
string, ulong, Throwable)`, candidates are:
 C:\D\dmd2\windows\bin\..\..\src\druntime\import\object.d(2440,30):       
`object.Exception.this(string msg, string file = __FILE__, uint line =
cast(uint)__LINE__, Throwable nextInChain = null)`
 C:\D\dmd2\windows\bin\..\..\src\druntime\import\object.d(2445,30):       
`object.Exception.this(string msg, Throwable nextInChain, string file =
__FILE__, uint line = cast(uint)__LINE__)`
 C:\D\dmd2\windows\bin\dmd.exe failed with exit code 1.
 ```
The error is from line 137 of node_dlang.d. Looking at it, we see this: ```d super (message, file, line, nextInChain); ``` This is in the constructor of the `JSException` class, a subclass of `Exception`, calling the superclass constructor. According to the error message, one or more of the arguments in this list does not match any `Exception` constructor's parameter list. Looking closer, we can see that the arguments to the super constructor are all declared in the `JSException` constructor like this: ```d this ( napi_value jsException , string message = `JS Exception` , string file = __FILE__ , ulong line = cast (ulong) __LINE__ , Throwable nextInChain = null) ``` Compare that with the constructors in the `Exception` class and you should see that the problem is `ulong line`. The equivalent argument in the superclass is `size_t`. In 32-bit, `size_t` is defined as `uint`, not `ulong`. So it's passing a `ulong` to a `uint`, which is a no-no. The `JSException` constructor should be modified to this: ```d , size_t line = __LINE__ ``` The README does say it hasn't been tested with 32-bit. So there may be more such errors. Unrelated, but I recommend you use `--arch=x86_mscoff` so that you can use the same linker and object file format as `-m64` uses (MS link, or lld, and PE/COFF), rather than the default (which is OPTLINK and OMF). It may save you further potential headaches.
Jun 06
parent Jack <jckj33 gmail.com> writes:
On Sunday, 6 June 2021 at 17:32:57 UTC, Mike Parker wrote:
 On Sunday, 6 June 2021 at 15:42:55 UTC, Jack wrote:
 0.4.11\node_dlang\source\node_dlang.d(137,11): Error: none of 
 the overloads of `this` are callable using argument types 
 `(string, string, ulong, Throwable)`, candidates are:
 [...]
The error is from line 137 of node_dlang.d. Looking at it, we see this: ```d super (message, file, line, nextInChain); ``` This is in the constructor of the `JSException` class, a subclass of `Exception`, calling the superclass constructor. According to the error message, one or more of the arguments in this list does not match any `Exception` constructor's parameter list. Looking closer, we can see that the arguments to the super constructor are all declared in the `JSException` constructor like this: ```d this ( napi_value jsException , string message = `JS Exception` , string file = __FILE__ , ulong line = cast (ulong) __LINE__ , Throwable nextInChain = null) ``` Compare that with the constructors in the `Exception` class and you should see that the problem is `ulong line`. The equivalent argument in the superclass is `size_t`. In 32-bit, `size_t` is defined as `uint`, not `ulong`. So it's passing a `ulong` to a `uint`, which is a no-no. The `JSException` constructor should be modified to this: ```d , size_t line = __LINE__ ```
Thanks, I managed to get out this error by making everything 64bit so no type sizes mismatch anymore. The electron itself was still 32bit, which was causing the error to load but it was gone once I reinstalled the 64version.
 The README does say it hasn't been tested with 32-bit. So there 
 may be more such errors.

 Unrelated, but I recommend you use `--arch=x86_mscoff`
thanks for the tip. in this case, i get the same error above not found the proper overload. But it's to avoid futher potential headaches, I'll edit the node_dlang.d file to make it work. Thanks!
 so that you can use the same linker and object file format as 
 `-m64` uses (MS link, or lld, and PE/COFF), rather than the 
 default (which is OPTLINK and OMF). It may save you further 
 potential headaches.
Jun 06
prev sibling parent reply NotSpooky <zoteman94 gmail.com> writes:
On Sunday, 6 June 2021 at 04:25:39 UTC, Jack wrote:
 I'm trying to use the node_dlang pakckage but the code example 
 from [this 
 repo](https://github.com/NotSpooky/node_dlang/tree/v0.4.11/examples) isn't
working

 the command ```dub build``` is fine but ```node example.js``` 
 retuns an error saying the module.node is not a valid win32 
 application. How do I fix this?

 [1]: 
 https://github.com/NotSpooky/node_dlang/tree/v0.4.11/examples
Hello, I'm the author of the library. Indeed I only tested it on 64-bit systems. I can try to make it 32-bit compatible if needed. Aside from the auto-translated headers, in the case of Windows the repo also includes node.lib compiled for 64-bit, so unless the 32-bit version is added it will also give errors. I'm pretty sure it does work with electron as I have used it myself.
Jun 06
parent reply Jack <jckj33 gmail.com> writes:
On Sunday, 6 June 2021 at 21:44:44 UTC, NotSpooky wrote:
 On Sunday, 6 June 2021 at 04:25:39 UTC, Jack wrote:
 I'm trying to use the node_dlang pakckage but the code example 
 from [this 
 repo](https://github.com/NotSpooky/node_dlang/tree/v0.4.11/examples) isn't
working

 the command ```dub build``` is fine but ```node example.js``` 
 retuns an error saying the module.node is not a valid win32 
 application. How do I fix this?

 [1]: 
 https://github.com/NotSpooky/node_dlang/tree/v0.4.11/examples
Hello, I'm the author of the library.
nice works, thanks for the library!
 Indeed I only tested it on 64-bit systems. I can try to make it 
 32-bit compatible if needed.
for me i think it would be needed, i made everything 64bit so it at least compiled and ran.
 Aside from the auto-translated headers, in the case of Windows 
 the repo also includes node.lib compiled for 64-bit, so unless 
 the 32-bit version is added it will also give errors.

 I'm pretty sure it does work with electron as I have used it 
 myself.
I managed to compile the module and it passed this test: ```javascript const nativeModule = require('./module.node'); const assert = require('assert'); assert(nativeModule.ultimate() == 42); ``` The D code looks like this: ```d import std.stdio : stderr; import node_dlang; extern(C): void atStart(napi_env env) { import std.stdio; writeln ("Hello from D!"); } int ultimate() { return 42; } mixin exportToJs! (ultimate, MainFunction!atStart); ``` its builds sucessfully with ```dub``` no arguments (no --arch=x86_mscoff yet because it requires to fix other compilation error). The dub script looks like this: ```json { "authors": [ "test" ], "copyright": "Copyright © 2021, test", "dependencies": { "node_dlang": "~>0.4.11" }, "description": "using electron from D", "license": "proprietary", "name": "eled", "targetType": "dynamicLibrary", "targetName" : "module.node", "targetPath": "bin" } ``` then i test with node: ``` node test.js ``` it works fine. However, when I attempt to use it in the prescript within electron, I get this error: ``` A JavaScript error occured in the browser process --------------------------- Uncaught Exception: Error: A dynamic link library (DLL) initialization routine failed. \\?\C:\Users\001\Desktop\ele\module.node at process.func [as dlopen] (VM70 asar_bundle.js:5) at Object.Module._extensions..node (VM43 loader.js:1138) at Object.func [as .node] (VM70 asar_bundle.js:5) at Module.load (VM43 loader.js:935) at Module._load (VM43 loader.js:776) at Function.f._load (VM70 asar_bundle.js:5) at Function.o._load (VM75 renderer_init.js:33) at Module.require (VM43 loader.js:959) at require (VM50 helpers.js:88) at Object.<anonymous> (VM88 C:\Users\001\Desktop\ele\preload.js:6) ``` the lines of this in the prescript goes like this: ```javascript const nativeModule = require('./module.node'); const assert = require('assert'); assert(nativeModule.ultimate() == 42); ``` What am I missing?
Jun 06
next sibling parent reply MoonlightSentinel <moonlightsentinel disroot.org> writes:
On Monday, 7 June 2021 at 02:33:38 UTC, Jack wrote:
 What am I missing?
Does your code / `node_dlang` initialize Druntime before calling `writeln`? Try replacing the `writeln` with `puts` (from `core.stdc.stdio`) which doesn't require an initialized runtime.
Jun 07
parent reply Jack <jckj33 gmail.com> writes:
On Monday, 7 June 2021 at 17:22:48 UTC, MoonlightSentinel wrote:
 On Monday, 7 June 2021 at 02:33:38 UTC, Jack wrote:
 What am I missing?
Does your code / `node_dlang` initialize Druntime before calling `writeln`?
actually i didnt so I just added: ```d shared static this() { Runtime.initialize(); } shared static ~this() { Runtime.terminate(); } ``` but it didn't change anything
 Try replacing the `writeln` with `puts` (from 
 `core.stdc.stdio`) which doesn't require an initialized runtime.
I've tried just removed the writeln() call it didn't change anything either
Jun 07
parent reply MoonlightSentinel <moonlightsentinel disroot.org> writes:
On Monday, 7 June 2021 at 19:03:44 UTC, Jack wrote:
 actually i didnt so I just added:

 ```d
 shared static this()
 {
 	Runtime.initialize();
 }

 shared static ~this()
 {
 	Runtime.terminate();
 }
 ```

 but it didn't change anything
That doesn't work because `Runtime.initialize()` is responsible to execute the module ctors. You could try `pragma(crt_constructor)`[1] instead. [1] https://dlang.org/spec/pragma.html#crtctor
Jun 07
parent Jack <jckj33 gmail.com> writes:
On Monday, 7 June 2021 at 20:37:19 UTC, MoonlightSentinel wrote:
 On Monday, 7 June 2021 at 19:03:44 UTC, Jack wrote:
 actually i didnt so I just added:

 ```d
 shared static this()
 {
 	Runtime.initialize();
 }

 shared static ~this()
 {
 	Runtime.terminate();
 }
 ```

 but it didn't change anything
That doesn't work because `Runtime.initialize()` is responsible to execute the module ctors. You could try `pragma(crt_constructor)`[1] instead. [1] https://dlang.org/spec/pragma.html#crtctor
I see, thanks for pointing out. I think the entry point function is the one set by MainFunction in the exportToJs template so I guess there's no need to this or DllMain. the [example](https://github.com/NotSpooky/node_dlang/blob/master/examples/type_exampl s/source/example.d) from the node_dlang have no other entry function than the defined by MainFunction template
Jun 07
prev sibling parent reply frame <frame86 live.com> writes:
On Monday, 7 June 2021 at 02:33:38 UTC, Jack wrote:

 What am I missing?
If this runs under Windows, there is no dlopen(), maybe a wrapper to LoadLibrary() but this will need to call a DllMain() in the DLL if I am not wrong. Is there a DllMain?
Jun 07
next sibling parent Jack <jckj33 gmail.com> writes:
On Monday, 7 June 2021 at 20:13:03 UTC, frame wrote:
 On Monday, 7 June 2021 at 02:33:38 UTC, Jack wrote:

 What am I missing?
If this runs under Windows, there is no dlopen(), maybe a wrapper to LoadLibrary() but this will need to call a DllMain() in the DLL if I am not wrong. Is there a DllMain?
I just noticied that's supposed to have a DllMain even tho the [code example](https://github.com/NotSpooky/node_dlang/blob/master/examples/type_exampl s/source/example.d) from node_dlang doesn't have one and it was working(?) I added one in my code but it give same error. I added like this: ```d module foo; import std.stdio : stderr; import node_dlang; import core.sys.windows.windows; import core.sys.windows.dll; mixin SimpleDllMain; extern(C): void atStart(napi_env env) { import std.stdio; writeln (`Loaded D native library!`); } int ultimate() { return 43; } mixin exportToJs! (ultimate, MainFunction!atStart); ```
Jun 07
prev sibling parent reply Jack <jckj33 gmail.com> writes:
On Monday, 7 June 2021 at 20:13:03 UTC, frame wrote:
 On Monday, 7 June 2021 at 02:33:38 UTC, Jack wrote:

 What am I missing?
If this runs under Windows, there is no dlopen(), maybe a wrapper to LoadLibrary() but this will need to call a DllMain() in the DLL if I am not wrong. Is there a DllMain?
I think the entry point function is ```void atStart(napi_env env) {}``` so there's no DllMain...
Jun 07
parent reply Mike Parker <aldacron gmail.com> writes:
On Monday, 7 June 2021 at 22:24:03 UTC, Jack wrote:
 I think the entry point function is ```void atStart(napi_env 
 env) {}``` so there's no DllMain...
DLLMain is not strictly required. It's called by the system loader when the DLL is first loaded into the process. The MainFunction for node is just a means for having a cross-platform approach to initialization: node will load your shared library then call the MainFunction. So you can initialize the runtime in DLLMain or in your atStart function. Shouldn't matter. Your problem may be unrelated to D, though. It appears to be a common error when developing native code for Electron. Googling for "electron {paste error message here}" or for "electron dll initialization" turns up several results. Some cursory reading shows that the issue may be a version mismatch between the version of node the dll was linked with and that used by Electron.
Jun 07
parent reply Jack <jckj33 gmail.com> writes:
On Tuesday, 8 June 2021 at 00:00:50 UTC, Mike Parker wrote:
 On Monday, 7 June 2021 at 22:24:03 UTC, Jack wrote:
 I think the entry point function is ```void atStart(napi_env 
 env) {}``` so there's no DllMain...
DLLMain is not strictly required. It's called by the system loader when the DLL is first loaded into the process. The MainFunction for node is just a means for having a cross-platform approach to initialization: node will load your shared library then call the MainFunction. So you can initialize the runtime in DLLMain or in your atStart function. Shouldn't matter.
i see
 Your problem may be unrelated to D, though. It appears to be a 
 common error when developing native code for Electron. Googling 
 for "electron {paste error message here}" or for "electron dll 
 initialization" turns up several results.
I'm googling this has been hours, none of the solutions worked for me, including rebuild the native module with electron-rebuild package
 Some cursory reading shows that the issue may be a version 
 mismatch between the version of node the dll was linked with 
 and that used by Electron.
the dll which I was just build with dub command? how I have a version mismatch if they're the very same file?
Jun 07
parent reply Mike Parker <aldacron gmail.com> writes:
On Tuesday, 8 June 2021 at 00:58:12 UTC, Jack wrote:

 the dll which I was just build with dub command? how I have a 
 version mismatch if they're the very same file?
Electron embeds node and does not use whatever you have on your system. So if there’s a mismatch between the embedded version and the one you linked against, you can see the error you’re seeing.
Jun 07
next sibling parent reply NotSpooky <zoteman94 gmail.com> writes:
On Tuesday, 8 June 2021 at 03:04:39 UTC, Mike Parker wrote:
 On Tuesday, 8 June 2021 at 00:58:12 UTC, Jack wrote:

 the dll which I was just build with dub command? how I have a 
 version mismatch if they're the very same file?
Electron embeds node and does not use whatever you have on your system. So if there’s a mismatch between the embedded version and the one you linked against, you can see the error you’re seeing.
I don't use Windows often, my bad for incompatibilities there. I updated Electron, node and DMD. After running console.log (process.versions) in Electron I get: { node: '14.16.0', v8: '9.1.269.28-electron.0', uv: '1.40.0', zlib: '1.2.11', brotli: '1.0.9', ares: '1.16.1', modules: '89', nghttp2: '1.41.0', napi: '7', llhttp: '2.1.3', openssl: '1.1.1', icu: '68.1', unicode: '13.0', electron: '13.1.1', chrome: '91.0.4472.77' } So I changed node.lib in node_dlang with the version from https://nodejs.org/download/release/v14.16.0/win-x64/ However, I get an Error: A dynamic link library (DLL) initialization routine failed. So I'll have to check what's happening now. It might be some API change in Node-API or something spookier. These days I'm quite busy but will do my best to fix this.
Jun 07
parent Jack <jckj33 gmail.com> writes:
On Tuesday, 8 June 2021 at 04:56:27 UTC, NotSpooky wrote:
 On Tuesday, 8 June 2021 at 03:04:39 UTC, Mike Parker wrote:
 On Tuesday, 8 June 2021 at 00:58:12 UTC, Jack wrote:

 [...]
Electron embeds node and does not use whatever you have on your system. So if there’s a mismatch between the embedded version and the one you linked against, you can see the error you’re seeing.
I don't use Windows often, my bad for incompatibilities there. I updated Electron, node and DMD. After running console.log (process.versions) in Electron I get: { node: '14.16.0', v8: '9.1.269.28-electron.0', uv: '1.40.0', zlib: '1.2.11', brotli: '1.0.9', ares: '1.16.1', modules: '89', nghttp2: '1.41.0', napi: '7', llhttp: '2.1.3', openssl: '1.1.1', icu: '68.1', unicode: '13.0', electron: '13.1.1', chrome: '91.0.4472.77' } So I changed node.lib in node_dlang with the version from https://nodejs.org/download/release/v14.16.0/win-x64/ However, I get an Error: A dynamic link library (DLL) initialization routine failed. So I'll have to check what's happening now. It might be some API change in Node-API or something spookier. These days I'm quite busy but will do my best to fix this.
Could you give me some direction how fix that, as mentioned by Mike Parker? I don't much about the details, I just started it a couple of days ago but as i need it working as soon as possible, I would try fix it myself. Otherwise I'll try use C++ and call my D stuff from there
Jun 08
prev sibling parent Jack <jckj33 gmail.com> writes:
On Tuesday, 8 June 2021 at 03:04:39 UTC, Mike Parker wrote:
 On Tuesday, 8 June 2021 at 00:58:12 UTC, Jack wrote:

 the dll which I was just build with dub command? how I have a 
 version mismatch if they're the very same file?
Electron embeds node and does not use whatever you have on your system. So if there’s a mismatch between the embedded version and the one you linked against, you can see the error you’re seeing.
I know I took way too much of your time... but could you give just some overalls directions on how to make fix that? can I set that dll which gets embeded in electron? where does it take it initially from? it's embbeded in the binaries? I'm new to electron so I'm figuring out
Jun 08