digitalmars.D.learn - how do i fix this node_dlang error?
- Jack (7/7) Jun 05 2021 I'm trying to use the node_dlang pakckage but the code example
- Mike Parker (9/17) Jun 05 2021 Looking at node_dlang's dub.json, it's building a DLL then
- Jack (5/25) Jun 06 2021 that's right, I was on 64bit system and node was 32bit
- Jack (17/37) Jun 06 2021 the npm was 32bit so the switch to 64bit worked then npm
- Mike Parker (39/43) Jun 06 2021 On Sunday, 6 June 2021 at 15:42:55 UTC, Jack wrote:
- Jack (9/51) Jun 06 2021 Thanks, I managed to get out this error by making everything
- NotSpooky (9/17) Jun 06 2021 Hello, I'm the author of the library.
- Jack (77/96) Jun 06 2021 for me i think it would be needed, i made everything 64bit so it
- MoonlightSentinel (5/6) Jun 07 2021 Does your code / `node_dlang` initialize Druntime before calling
- Jack (15/21) Jun 07 2021 actually i didnt so I just added:
- MoonlightSentinel (5/17) Jun 07 2021 That doesn't work because `Runtime.initialize()` is responsible
- Jack (5/25) Jun 07 2021 I see, thanks for pointing out. I think the entry point function
- frame (4/5) Jun 07 2021 If this runs under Windows, there is no dlopen(), maybe a wrapper
- Jack (23/28) Jun 07 2021 I just noticied that's supposed to have a DllMain even tho the
- Jack (3/8) Jun 07 2021 I think the entry point function is ```void atStart(napi_env env)
- Mike Parker (14/16) Jun 07 2021 DLLMain is not strictly required. It's called by the system
- Jack (7/25) Jun 07 2021 I'm googling this has been hours, none of the solutions worked
- Mike Parker (4/6) Jun 07 2021 Electron embeds node and does not use whatever you have on your
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 2021
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/examplesLooking 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 2021
Jack <jckj33 gmail.com> 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: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!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/examplesLooking 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 06 2021
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: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. ```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/examplesLooking 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 06 2021
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 2021
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: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 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`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 2021
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/examplesHello, 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 2021
On Sunday, 6 June 2021 at 21:44:44 UTC, NotSpooky wrote:On Sunday, 6 June 2021 at 04:25:39 UTC, Jack wrote:nice works, thanks for the library!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/examplesHello, 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.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 2021
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 2021
On Monday, 7 June 2021 at 17:22:48 UTC, MoonlightSentinel wrote:On Monday, 7 June 2021 at 02:33:38 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 anythingWhat 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.I've tried just removed the writeln() call it didn't change anything either
Jun 07 2021
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 2021
On Monday, 7 June 2021 at 20:37:19 UTC, MoonlightSentinel wrote:On Monday, 7 June 2021 at 19:03:44 UTC, Jack wrote: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 templateactually i didnt so I just added: ```d shared static this() { Runtime.initialize(); } shared static ~this() { Runtime.terminate(); } ``` but it didn't change anythingThat 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 2021
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 2021
On Monday, 7 June 2021 at 20:13:03 UTC, frame wrote:On Monday, 7 June 2021 at 02:33:38 UTC, Jack wrote: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); ```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 2021
On Monday, 7 June 2021 at 20:13:03 UTC, frame wrote:On Monday, 7 June 2021 at 02:33:38 UTC, Jack wrote:I think the entry point function is ```void atStart(napi_env env) {}``` so there's no DllMain...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 2021
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 2021
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 seeI 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.I'm googling this has been hours, none of the solutions worked for me, including rebuild the native module with electron-rebuild packageSome 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 2021
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 2021
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: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.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 2021
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: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 thereOn Tuesday, 8 June 2021 at 00:58:12 UTC, Jack wrote: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.[...]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 08 2021
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: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 outthe 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 08 2021