Unable to build and run C++ addon in Windows 8.1 x64 #965

metabench · 2015-02-26T08:26:55Z

I'm trying to use iojs 1.3.0 (Windows 8.1 x64), with a module written using nan, with nan 1.6.2 installed. It worked fine in node 0.12.0.

First I had problems with node-gyp looking for node.lib rather than iojs.lib. I got round that using pangyp.

When I tried running the JavaScript that references the addon, I got
Error: Module did not self-register.

I've found a reference to a similar seeming issue with node-sass here: sass/node-sass#708

The text was updated successfully, but these errors were encountered:

bnoordhuis · 2015-02-26T11:56:12Z

Can you try using the npm / node-gyp that comes with io.js? The 'module did not self-register' error suggests that the module was built for the wrong version (probably node.js rather than io.js.)

metabench · 2015-02-26T12:01:28Z

I will try that soon. Currently I have both iojs and node uninstalled. I'll go get a sandwich, and then install iojs again. I'll try to use the versions of the tools that come with iojs and I'll report back how I get on.

metabench · 2015-02-26T12:18:20Z

No sandwich yet... but I've installed iojs, I think I am using the right tools, and ran into the same problem as before.

This time I went to the C:\Program Files\iojs directory and ran
npm install node-gyp -g. Maybe that is my problem as I may then be using the old (or current release) version of node-gyp to do the build. However, I don't know how to choose a specific node-gyp to use from the command line.

metabench · 2015-02-26T13:01:29Z

@bnoordhuis When I run "node-gyp -v" from either the iojs or my project's C++ path I get v1.0.2.

As far as I know I'm not using the old version of node-gyp, but I don't know how to be sure about that. I don't know where to find the node-gyp that came with iojs.

bnoordhuis · 2015-02-26T13:23:27Z

@metabench v1.0.2 is the node-gyp version that ships with io.js. Can you tell what URL it downloads the source tarball from?

BTW, the node-gyp script itself is pretty well hidden, it's in npm's node_modules/node-gyp/bin directory.

metabench · 2015-02-26T13:25:55Z

@bnoordhuis I'd like to tell you that, but I don't know when it downloads a source tarball, or when I see the URL.

bnoordhuis · 2015-02-26T13:30:02Z

It should be in npm-debug.log somewhere. You may have to remove the cache first. It's in $HOME/.node-gyp on Unices. I believe it's %USERPROFILE%\\.node-gyp on Windows.

metabench · 2015-02-26T13:36:38Z

@bnoordhuis I could not see any .log files within my user profile's .node-gyp directory (I searched for *.log). I just see: {'directories': ['deps', 'ia32', 'Release', 'src', 'tools', x64], 'files': ['comon.gypi', 'installVersion']}

metabench · 2015-02-26T13:43:46Z

@bnoordhuis 'You may have to remove the cache first' - I don't know what cache you mean.

bnoordhuis · 2015-02-26T14:05:12Z

node-gyp downloads the source tarball from (if all is well) iojs.org but it caches it locally so it doesn't have to redownload it every time you build an add-on.

The npm-debug.log file is normally written to the directory you ran npm install whatever in. If you run node-gyp directly, there will be no such file, everything will be logged to the console.

metabench · 2015-02-26T14:07:26Z

@bnoordhuis Would that be the source tarball that node-gyp downloads when it installs?

metabench · 2015-02-26T14:30:53Z

@bnoordhuis I did not see it download a tarball after I installed iojs from the Windows installer. I do remember node-gyp had downloaded tarballs of node in the past though.

metabench · 2015-02-26T17:34:06Z

@bnoordhuis and all, I have solved the problem I was having.

There may have been a few things wrong with my setup here, I'm not sure which step got it to run. That said, I'll describe what I did.

Uninstall node
Uninstall iojs
Install iojs, with all options selected
Delete all files that had been built in my project
(verify that I can actually install and run C++ addons, using npm install binaryjs and npm install mmmagic, then loading them through the node terminal with require)
Go to my project's directory in the command prompt
run npm install

I had been having problems because rather than doing npm install, I had been doing node-gyp configure, node-gyp build.

I think there still is an issue with iojs not easily running as a drop-in replacement for node while keeping exactly the same work-flow.

Do people agree there is still an issue here? I think the issue software-wise is far less severe than I had thought at first, but there is still a problem because something no longer works like it used to.

mscdex · 2015-02-26T18:52:54Z

@metabench I think the issue is still that the node-gyp bundled with iojs/npm is a fork that allows it to work with iojs (pulling in the right tarball, etc). When you use the node-gyp from npm install node-gyp -g, you get a version that is (as far as I know) still node-only.

I suggested using npm install . because that uses the iojs npm which uses the iojs copy of node-gyp. You could also use the full path to the iojs node-gyp, but that can be more cumbersome.

mathiask88 · 2015-02-28T01:01:37Z

Unfortunately there is a bug calling a native module in iojs. I can confirm the "not self-register" error on windows if I start a js file (that requires a native module) with "node" instead of "iojs" in the cmd.

mathiask88 · 2015-02-28T10:24:34Z

My c++ knowledge is limited, but maybe this will help. If I run iojs with node.exe hardlink the node_is_initialized variable (node.cc) magically is set to false after the native module is loaded in https://github.com/iojs/io.js/blob/v1.x/src/node.cc#L2057. As the result the node_module_register function thinks the native module is a "Linked" module (https://github.com/iojs/io.js/blob/v1.x/src/node.cc#L2001), so the modpending is not set and a "Module did not self-register." is thrown.

metabench · 2015-02-28T10:31:17Z

@mathiask88 I can confirm I run into that error when I use the 'node' command to start my app. When I start with 'iojs' it's OK.

However, I had been previously been encountering that same "Module did not self-register" error when starting with the 'iojs' command, having having built using 'pangyp' (because 'node-gyp build' would not work).

bnoordhuis · 2015-02-28T10:35:02Z

/cc @piscisaureus - is that a known issue?

mathiask88 · 2015-02-28T10:38:14Z

Hm.. I found out, that the node_is_initialized variable is false because the node_module_register got an ambiguity and the program just goes for the wrong way ;) But here I am really at my wit's end.

bnoordhuis · 2015-02-28T11:00:40Z

Oh... could it be that the patch below resolves that? It's paramount that the add-on is built with BUILDING_NODE_EXTENSION defined.

diff --git a/src/node.cc b/src/node.cc
index d75f0d0..c56ef90 100644
--- a/src/node.cc
+++ b/src/node.cc
@@ -1992,7 +1992,7 @@ void Hrtime(const FunctionCallbackInfo<Value>& args) {
   args.GetReturnValue().Set(tuple);
 }

-extern "C" void node_module_register(void* m) {
+extern "C" NODE_EXTERN void node_module_register(void* m) {
   struct node_module* mp = reinterpret_cast<struct node_module*>(m);

   if (mp->nm_flags & NM_F_BUILTIN) {

mathiask88 · 2015-02-28T11:30:52Z

@bnoordhuis Added the NODE_EXTERN,checked for BUILDING_NODE_EXTENSION and rebuilt iojs and the addon but the behavior is still the same.

reklatsmasters · 2015-03-01T10:59:08Z

I have windows 7 x64 and the same error. I use pangyp for build.
[email protected] - successful run.
[email protected] ~ [email protected] - Module did not self-register

metabench · 2015-03-01T11:01:11Z

@reklatsmasters are you sure you have those the right way round? What you have reported is the opposite to what I have, because I can run it with the 'iojs' command, but get the error calling it with 'node'.

reklatsmasters · 2015-03-01T11:12:56Z

@metabench you are right. I used mocha for starting, and it uses 'node'.

pgbross · 2015-03-08T15:41:34Z

I have been puzzling about the behaviour of C++ extensions (such as mongodb/js-bson) on Windows with iojs, and on reading this thread realized that the name of the "node" executable must match the name used by the "build" process, so running with 'iojs' command works.

On looking at the node.cc sources, registering a c++ extension essentially is a call to uv_dlopen(), which in turn calls the Windows LoadLibraryEx() function to load the module into the program's address space. I then used the Dependency Walker (www.dependencywalker.com) to analyze the ".node" module from the hello world example.

where it is showing a dependency on IOJS.EXE.

So if an application is run with the 'node' command, then when it dynamically loads loads the c++ extensions, it will load a copy of the specified dependency IOJS.EXE. At that point there will be multiple methods called 'node_module_register' and the plugin module will dutifully call the one it thinks it is dependent on (the one in IOJS.EXE), but that is not the one in node.exe we started the application with, so node.exe is unaware of any registration calls. Therefore, once the dynamic loading is complete (as far as uv_dlopen() is concerned), the module will appear not to have registered itself and thus the "Module did not self register" error is thrown.

As far as I can see on Windows, there is no way round this problem whilst 'iojs' is a single .exe, and one must ensure that when a c++ extension is in use, you must use the 'iojs' command. I suspect that if the iojs.exe was modified to be a small .exe and a .dll, then there would be no trouble loading extensions, regardless of the name of the .exe (though that might introduce lots more issues of course).

There is an issue io.js/issues/871 that discusses the possibility of having the 'node' command be a shortcut instead of a hardlink, but the conclusion in that issue appears to be that doing this would introduce some undesirable side effects, so is not being pursued.

--philip

am11 · 2015-03-09T22:52:58Z

@pgbross, nice findings. 👍

I didn't knew about dependencywalker, but I was probing it with this other tool Windbg, which comes packed with Windows SDK. See this blog. Windbg lets you walk through the module loader execution steps on attaching the debugger to the executable or any binary image.

This is related to #751.

The gist is; in order to dynamically resolve the module path, the uv's windows util code would probably need to make use of 'adjustor thunk' to modify the vtable at execution time.

I tried playing with it, but hit a blocker pretty quickly. Since this is some low-level system programming stuff, someone with real hands-on OS calls can probably provide the better solution here. Probably its just a hacking 101 for such a person or we may able to fix it by switching the lib paths register in assembly? Who knows..

If you know about other ways of dynamic module loading in Windows, please provide some pointers at #751 or you may want to continue your research based on the possibilities shared by @kkoopa and others.

On Windows, when node or io.js attempts to dynamically load a compiled addon, the compiled addon tries to load node.exe or iojs.exe again - depending on which import library the module used when it was linked. This makes it impossible to rename node.exe or iojs.exe, because when that happens the module can't find its dependencies. With this patch, a delay-load hook is added to all modules that are compiled with node-gyp. The delay-load hook ensures that whenever a module tries to load imports from node.exe/iojs.exe, it'll just refer back to the process image, thus making it possible to rename the iojs/node binary. Bug: nodejs/node#751 Bug: nodejs/node#965 Downstream PR: nodejs/node#1251

On Windows, when node or io.js attempts to dynamically load a compiled addon, the compiled addon tries to load node.exe or iojs.exe again - depending on which import library the module used when it was linked. This makes it impossible to rename node.exe or iojs.exe, because when that happens the module can't find its dependencies. With this patch, a delay-load hook is added to all modules that are compiled with node-gyp. The delay-load hook ensures that whenever a module tries to load imports from node.exe/iojs.exe, it'll just refer back to the process image, thus making it possible to rename the iojs/node binary. Bug: nodejs/node#751 Bug: nodejs/node#965 Downstream PR: nodejs/node#1251 PR-URL: nodejs#599 Reviewed-By: Ben Noordhuis <[email protected]>

On Windows, when node or io.js attempts to dynamically load a compiled addon, the compiled addon tries to load node.exe or iojs.exe again - depending on which import library the module used when it was linked. This makes it impossible to rename node.exe or iojs.exe, because when that happens the module can't find its dependencies. With this patch, a delay-load hook is added to all modules that are compiled with node-gyp. The delay-load hook ensures that whenever a module tries to load imports from node.exe/iojs.exe, it'll just refer back to the process image, thus making it possible to rename the iojs/node binary. Bug: nodejs#751 Bug: nodejs#965 Upstream PR: nodejs/node-gyp#599 PR-URL: nodejs#1251 Reviewed-By: Rod Vagg <[email protected]>

On Windows, when node or io.js attempts to dynamically load a compiled addon, the compiled addon tries to load node.exe or iojs.exe again - depending on which import library the module used when it was linked. This causes many compiled addons to break when node.exe or iojs.exe are renamed, because when the binary has been renamed the addon DLL can't find the (right) .exe file to load its imports from. This patch gives compiled addon developers an option to overcome this restriction by compiling a delay-load hook into their binary. The delay-load hook ensures that whenever a module tries to load imports from node.exe/iojs.exe, it'll just look at the process image, thereby making the addon work regardless of what name the node/iojs binary has. To enable this feature, the addon developer must set the 'win_delay_load_hook' option to 'true' in their binding.gyp file, like this: ``` { 'targets': [ { 'target_name': 'ernie', 'win_delay_load_hook': 'true', ... ``` Bug: #751 Bug: #965 Upstream PR: nodejs/node-gyp#599 PR-URL: #1251 Reviewed-By: Rod Vagg <[email protected]> PR-URL: #1266 Reviewed-By: Ben Noordhuis <[email protected]>

On Windows, when node or io.js attempts to dynamically load a compiled addon, the compiled addon tries to load node.exe or iojs.exe again - depending on which import library the module used when it was linked. This causes many compiled addons to break when node.exe or iojs.exe are renamed, because when the binary has been renamed the addon DLL can't find the (right) .exe file to load its imports from. This patch gives compiled addon developers an option to overcome this restriction by compiling a delay-load hook into their binary. The delay-load hook ensures that whenever a module tries to load imports from node.exe/iojs.exe, it'll just look at the process image, thereby making the addon work regardless of what name the node/iojs binary has. To enable this feature, the addon developer must set the 'win_delay_load_hook' option to 'true' in their binding.gyp file, like this: ``` { 'targets': [ { 'target_name': 'ernie', 'win_delay_load_hook': 'true', ... ``` Bug: nodejs/node#751 Bug: nodejs/node#965

On Windows, when node or io.js attempts to dynamically load a compiled addon, the compiled addon tries to load node.exe or iojs.exe again - depending on which import library the module used when it was linked. This causes many compiled addons to break when node.exe or iojs.exe are renamed, because when the binary has been renamed the addon DLL can't find the (right) .exe file to load its imports from. This patch gives compiled addon developers an option to overcome this restriction by compiling a delay-load hook into their binary. The delay-load hook ensures that whenever a module tries to load imports from node.exe/iojs.exe, it'll just look at the process image, thereby making the addon work regardless of what name the node/iojs binary has. To enable this feature, the addon developer must set the 'win_delay_load_hook' option to 'true' in their binding.gyp file, like this: ``` { 'targets': [ { 'target_name': 'ernie', 'win_delay_load_hook': 'true', ... ``` Bug: nodejs#751 Bug: nodejs#965 Upstream PR: nodejs/node-gyp#599 PR-URL: nodejs#1251 Reviewed-By: Rod Vagg <[email protected]> PR-URL: nodejs#1266 Reviewed-By: Ben Noordhuis <[email protected]>

On Windows, when node or io.js attempts to dynamically load a compiled addon, the compiled addon tries to load node.exe or iojs.exe again - depending on which import library the module used when it was linked. This causes many compiled addons to break when node.exe or iojs.exe are renamed, because when the binary has been renamed the addon DLL can't find the (right) .exe file to load its imports from. This patch gives compiled addon developers an option to overcome this restriction by compiling a delay-load hook into their binary. The delay-load hook ensures that whenever a module tries to load imports from node.exe/iojs.exe, it'll just look at the process image, thereby making the addon work regardless of what name the node/iojs binary has. To enable this feature, the addon developer must set the 'win_delay_load_hook' option to 'true' in their binding.gyp file, like this: ``` { 'targets': [ { 'target_name': 'ernie', 'win_delay_load_hook': 'true', ... ``` Bug: #751 Bug: #965 Upstream PR: nodejs/node-gyp#599 PR-URL: #1251 Reviewed-By: Rod Vagg <[email protected]> PR-URL: #1266 Reviewed-By: Ben Noordhuis <[email protected]>

On Windows, when node or io.js attempts to dynamically load a compiled addon, the compiled addon tries to load node.exe or iojs.exe again - depending on which import library the module used when it was linked. This causes many compiled addons to break when node.exe or iojs.exe are renamed, because when the binary has been renamed the addon DLL can't find the (right) .exe file to load its imports from. This patch gives compiled addon developers an option to overcome this restriction by compiling a delay-load hook into their binary. The delay-load hook ensures that whenever a module tries to load imports from node.exe/iojs.exe, it'll just look at the process image, thereby making the addon work regardless of what name the node/iojs binary has. To enable this feature, the addon developer must set the 'win_delay_load_hook' option to 'true' in their binding.gyp file, like this: ``` { 'targets': [ { 'target_name': 'ernie', 'win_delay_load_hook': 'true', ... ``` Bug: nodejs#751 Bug: nodejs#965 Upstream PR: nodejs/node-gyp#599 PR-URL: nodejs#1251 Reviewed-By: Rod Vagg <[email protected]> PR-URL: nodejs#1266 Reviewed-By: Ben Noordhuis <[email protected]>

On Windows, when node or io.js attempts to dynamically load a compiled addon, the compiled addon tries to load node.exe or iojs.exe again - depending on which import library the module used when it was linked. This causes many compiled addons to break when node.exe or iojs.exe are renamed, because when the binary has been renamed the addon DLL can't find the (right) .exe file to load its imports from. This patch gives compiled addon developers an option to overcome this restriction by compiling a delay-load hook into their binary. The delay-load hook ensures that whenever a module tries to load imports from node.exe/iojs.exe, it'll just look at the process image, thereby making the addon work regardless of what name the node/iojs binary has. To enable this feature, the addon developer must set the 'win_delay_load_hook' option to 'true' in their binding.gyp file, like this: ``` { 'targets': [ { 'target_name': 'ernie', 'win_delay_load_hook': 'true', ... ``` Bug: #751 Bug: #965 Upstream PR: nodejs/node-gyp#599 PR-URL: #1251 Reviewed-By: Rod Vagg <[email protected]> PR-URL: #1266 Reviewed-By: Ben Noordhuis <[email protected]>

On Windows, when node or io.js attempts to dynamically load a compiled addon, the compiled addon tries to load node.exe or iojs.exe again - depending on which import library the module used when it was linked. This causes many compiled addons to break when node.exe or iojs.exe are renamed, because when the binary has been renamed the addon DLL can't find the (right) .exe file to load its imports from. This patch gives compiled addon developers an option to overcome this restriction by compiling a delay-load hook into their binary. The delay-load hook ensures that whenever a module tries to load imports from node.exe/iojs.exe, it'll just look at the process image, thereby making the addon work regardless of what name the node/iojs binary has. To enable this feature, the addon developer must set the 'win_delay_load_hook' option to 'true' in their binding.gyp file, like this: ``` { 'targets': [ { 'target_name': 'ernie', 'win_delay_load_hook': 'true', ... ``` Bug: nodejs#751 Bug: nodejs#965 Upstream PR: nodejs/node-gyp#599 PR-URL: nodejs#1251 Reviewed-By: Rod Vagg <[email protected]> PR-URL: nodejs#1266 Reviewed-By: Ben Noordhuis <[email protected]>

Fishrock123 · 2015-05-06T20:09:38Z

Closing, as the delay-load hook is enabled by default in io.js 2.0.0, please report back if this is still an issue.

On Windows, when node or io.js attempts to dynamically load a compiled addon, the compiled addon tries to load node.exe or iojs.exe again - depending on which import library the module used when it was linked. This causes many compiled addons to break when node.exe or iojs.exe are renamed, because when the binary has been renamed the addon DLL can't find the (right) .exe file to load its imports from. This patch gives compiled addon developers an option to overcome this restriction by compiling a delay-load hook into their binary. The delay-load hook ensures that whenever a module tries to load imports from node.exe/iojs.exe, it'll just look at the process image, thereby making the addon work regardless of what name the node/iojs binary has. To enable this feature, the addon developer must set the 'win_delay_load_hook' option to 'true' in their binding.gyp file, like this: ``` { 'targets': [ { 'target_name': 'ernie', 'win_delay_load_hook': 'true', ... ``` Bug: nodejs#751 Bug: nodejs#965 Upstream PR: nodejs/node-gyp#599 PR-URL: nodejs#1251 Reviewed-By: Rod Vagg <[email protected]> PR-URL: nodejs#1266 Reviewed-By: Ben Noordhuis <[email protected]>

Fishrock123 added c++ Issues and PRs that require attention from people who are familiar with C++. and removed c++ Issues and PRs that require attention from people who are familiar with C++. labels Feb 26, 2015

pgbross mentioned this issue Mar 8, 2015

Hello World throws "Module did not self-register" with iojs (1.4.3) on Windows 8 x64 nodejs/node-addon-examples#22

Closed

mscdex added the c++ Issues and PRs that require attention from people who are familiar with C++. label Mar 9, 2015

This was referenced Mar 25, 2015

win: allow node.exe/iojs.exe to be renamed nodejs/node-gyp#599

Merged

node-gyp: allow node.exe/iojs.exe to be renamed #1251

Merged

Fishrock123 closed this as completed May 13, 2015

aliscco mentioned this issue Jun 23, 2023

[Snyk] Fix for 1 vulnerabilities aliscco/alisco-node#571

Open

leonardoadame mentioned this issue Jul 7, 2023

[Snyk] Fix for 4 vulnerabilities leonardoadame/node#56

Open

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Unable to build and run C++ addon in Windows 8.1 x64 #965

Unable to build and run C++ addon in Windows 8.1 x64 #965

metabench commented Feb 26, 2015

bnoordhuis commented Feb 26, 2015

metabench commented Feb 26, 2015

metabench commented Feb 26, 2015

metabench commented Feb 26, 2015

bnoordhuis commented Feb 26, 2015

metabench commented Feb 26, 2015

bnoordhuis commented Feb 26, 2015

metabench commented Feb 26, 2015

metabench commented Feb 26, 2015

bnoordhuis commented Feb 26, 2015

metabench commented Feb 26, 2015

metabench commented Feb 26, 2015

metabench commented Feb 26, 2015

mscdex commented Feb 26, 2015

mathiask88 commented Feb 28, 2015

mathiask88 commented Feb 28, 2015

metabench commented Feb 28, 2015

bnoordhuis commented Feb 28, 2015

mathiask88 commented Feb 28, 2015

bnoordhuis commented Feb 28, 2015

mathiask88 commented Feb 28, 2015

reklatsmasters commented Mar 1, 2015

metabench commented Mar 1, 2015

reklatsmasters commented Mar 1, 2015

pgbross commented Mar 8, 2015

am11 commented Mar 9, 2015

Fishrock123 commented May 6, 2015

Unable to build and run C++ addon in Windows 8.1 x64 #965

Unable to build and run C++ addon in Windows 8.1 x64 #965

Comments

metabench commented Feb 26, 2015

bnoordhuis commented Feb 26, 2015

metabench commented Feb 26, 2015

metabench commented Feb 26, 2015

metabench commented Feb 26, 2015

bnoordhuis commented Feb 26, 2015

metabench commented Feb 26, 2015

bnoordhuis commented Feb 26, 2015

metabench commented Feb 26, 2015

metabench commented Feb 26, 2015

bnoordhuis commented Feb 26, 2015

metabench commented Feb 26, 2015

metabench commented Feb 26, 2015

metabench commented Feb 26, 2015

mscdex commented Feb 26, 2015

mathiask88 commented Feb 28, 2015

mathiask88 commented Feb 28, 2015

metabench commented Feb 28, 2015

bnoordhuis commented Feb 28, 2015

mathiask88 commented Feb 28, 2015

bnoordhuis commented Feb 28, 2015

mathiask88 commented Feb 28, 2015

reklatsmasters commented Mar 1, 2015

metabench commented Mar 1, 2015

reklatsmasters commented Mar 1, 2015

pgbross commented Mar 8, 2015

am11 commented Mar 9, 2015

Fishrock123 commented May 6, 2015