June 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?

June 07, 2021

On Monday, 7 June 2021 at 19:03:44 UTC, Jack wrote:

>

actually i didnt so I just added:

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

June 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:

>

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 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:

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);
June 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:

>

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...

June 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:

>

actually i didnt so I just added:

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 from the node_dlang have no other entry function than the defined by MainFunction template

June 08, 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.

June 08, 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 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?

June 08, 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.

June 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:

>

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.

June 08, 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:

>

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