gyp: win_delay_load_hook is false again
#1667
Labels
confirmed-bug
Issues with confirmed bugs.
npm
Issues and PRs related to the npm client dependency or the npm registry.
windows
Issues and PRs related to the Windows platform.
Comments
mscdex
added
confirmed-bug
|
Fixed in 64d3210 |
|
Ah, noted, I'd forgot to check for that in the npm updates. |
Fishrock123
referenced
this issue
in npm/node
May 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]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
It looks like when npm was updated recently, one of the floated patches reverted the default value for
win_delay_load_hookinaddon.gypi.The text was updated successfully, but these errors were encountered: