-
Notifications
You must be signed in to change notification settings - Fork 28.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Unable to build and run C++ addon in Windows 8.1 x64 #965
Comments
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.) |
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. |
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 |
@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. |
@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. |
@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. |
It should be in npm-debug.log somewhere. You may have to remove the cache first. It's in |
@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']} |
@bnoordhuis 'You may have to remove the cache first' - I don't know what cache you mean. |
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 |
@bnoordhuis Would that be the source tarball that node-gyp downloads when it installs? |
@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. |
@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 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. |
@metabench I think the issue is still that the I suggested using |
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. |
My c++ knowledge is limited, but maybe this will help. If I run iojs with node.exe hardlink the |
@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). |
/cc @piscisaureus - is that a known issue? |
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) { |
@bnoordhuis Added the |
I have windows 7 x64 and the same error. I use |
@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'. |
@metabench you are right. I used |
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 |
@pgbross, nice findings. 👍 I didn't knew about 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
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 <info@bnoordhuis.nl>
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 <rod@vagg.org>
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 <rod@vagg.org> PR-URL: #1266 Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
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 <rod@vagg.org> PR-URL: nodejs#1266 Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
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 <rod@vagg.org> PR-URL: #1266 Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
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 <rod@vagg.org> PR-URL: nodejs#1266 Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
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 <rod@vagg.org> PR-URL: nodejs#1266 Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
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 <rod@vagg.org> PR-URL: nodejs#1266 Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
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 <rod@vagg.org> PR-URL: nodejs#1266 Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
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 <rod@vagg.org> PR-URL: #1266 Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
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 <rod@vagg.org> PR-URL: #1266 Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
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 <rod@vagg.org> PR-URL: #1266 Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
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 <rod@vagg.org> PR-URL: nodejs#1266 Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
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 <rod@vagg.org> PR-URL: nodejs#1266 Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
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 <rod@vagg.org> PR-URL: nodejs#1266 Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
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 <rod@vagg.org> PR-URL: nodejs#1266 Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
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 <rod@vagg.org> PR-URL: nodejs#1266 Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
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 <rod@vagg.org> PR-URL: nodejs#1266 Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
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 <rod@vagg.org> PR-URL: nodejs#1266 Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
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: