Skip to content
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

Closed
metabench opened this issue Feb 26, 2015 · 34 comments
Closed

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

metabench opened this issue Feb 26, 2015 · 34 comments
Labels
c++ Issues and PRs that require attention from people who are familiar with C++. windows Issues and PRs related to the Windows platform.

Comments

@metabench
Copy link

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

@bnoordhuis
Copy link
Member

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
Copy link
Author

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
Copy link
Author

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
Copy link
Author

@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
Copy link
Member

@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
Copy link
Author

@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
Copy link
Member

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
Copy link
Author

@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
Copy link
Author

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

@bnoordhuis
Copy link
Member

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
Copy link
Author

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

@metabench
Copy link
Author

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

@Fishrock123 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
@metabench
Copy link
Author

@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
Copy link
Contributor

mscdex commented Feb 26, 2015

@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
Copy link
Contributor

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
Copy link
Contributor

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
Copy link
Author

@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
Copy link
Member

/cc @piscisaureus - is that a known issue?

@mathiask88
Copy link
Contributor

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
Copy link
Member

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
Copy link
Contributor

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

@reklatsmasters
Copy link
Contributor

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
Copy link
Author

@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
Copy link
Contributor

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

@pgbross
Copy link

pgbross commented Mar 8, 2015

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.

hello

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

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

am11 commented Mar 9, 2015

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

piscisaureus added a commit to piscisaureus/node-gyp that referenced this issue Mar 25, 2015
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
piscisaureus added a commit to piscisaureus/node-gyp that referenced this issue Mar 25, 2015
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
piscisaureus added a commit to piscisaureus/node-gyp that referenced this issue Mar 25, 2015
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]>
othiym23 pushed a commit to npm/node that referenced this issue Mar 27, 2015
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]>
piscisaureus added a commit that referenced this issue Mar 30, 2015
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]>
piscisaureus added a commit to piscisaureus/node-gyp that referenced this issue Mar 30, 2015
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
othiym23 pushed a commit to npm/node that referenced this issue Apr 3, 2015
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]>
piscisaureus added a commit that referenced this issue Apr 4, 2015
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]>
othiym23 pushed a commit to npm/node that referenced this issue Apr 10, 2015
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]>
othiym23 pushed a commit to npm/node that referenced this issue Apr 10, 2015
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]>
othiym23 pushed a commit to npm/node that referenced this issue Apr 10, 2015
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]>
othiym23 pushed a commit to npm/node that referenced this issue Apr 17, 2015
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]>
piscisaureus added a commit that referenced this issue Apr 17, 2015
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]>
piscisaureus added a commit that referenced this issue Apr 17, 2015
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]>
piscisaureus added a commit that referenced this issue Apr 17, 2015
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]>
othiym23 pushed a commit to npm/node that referenced this issue Apr 24, 2015
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]>
othiym23 pushed a commit to npm/node that referenced this issue May 1, 2015
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]>
othiym23 pushed a commit to npm/node that referenced this issue May 1, 2015
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]>
othiym23 pushed a commit to npm/node that referenced this issue May 1, 2015
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]>
othiym23 pushed a commit to npm/node that referenced this issue May 2, 2015
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
Copy link
Contributor

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.

othiym23 pushed a commit to npm/node that referenced this issue May 8, 2015
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]>
iarna pushed a commit to npm/node that referenced this issue May 22, 2015
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]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
c++ Issues and PRs that require attention from people who are familiar with C++. windows Issues and PRs related to the Windows platform.
Projects
None yet
Development

No branches or pull requests

10 participants