Repository navigation
Windows: Broken node alias #751
Description
Activity
/cc @piscisaureus
do we need to do that stub executable after all?
Perhaps node.exe can spawn iojs.exe with the same command line arguments and redirected stdin, stdout and stderr?
This issue is that the name of the library that compiled addons link against is fixed. For this reason it also has never been possible to rename node.exe on windows and have compiled addons still work.
In theory this issue could be solved by delay-loading the symbols that come from iojs.exe and adding a delay-load notification hook to the compiled addon.
Unfortunately I've never gotten around to implementing this.
do we need to do that stub executable after all?
The original plan I had where node.exe would "load" iojs.exe as a dynamic library turned out not to work.
Perhaps node.exe can spawn iojs.exe with the same command line arguments and redirected stdin, stdout and stderr?
That's possible but it I'm afraid it'll break other scripts that assume that they can obtain the PID for their child node process.
At this point it also breaks clustering.delayload might not work. It is not allowed to delay-load imported data, which happens when someone uses
v8::String::ExternalStringResourcewhich is a class exported from v8 with virtual members. Cannot link without the vtable.LINK : fatal error LNK1194: cannot delay-load 'iojs.exe' due to import of data symbol '"__declspec(dllimport) const v8::String::ExternalStringResource::`vftable'" (__imp_??_7ExternalStringResource@String@v8@@6B@)'; link without /DELAYLOAD:iojs.exedelayload might not work. It is not allowed to delay-load imported data, which happens when someone uses v8::String::ExternalStringResource which is a class exported from v8 with virtual members. Cannot link without the vtable.
Right, I didn't think of that.
I don't have any other ideas at this point.Is it possible to break out all shared functionality into a real dynamic library, make addons link against that and have two thin frontends, "node.exe" and "iojs.exe"? Addons would then not necessarily be tied to executable names. If there still is a need for a registration callback inside the frontends then that can be found by dynamically loading the right library based on
GetModuleFileName.In short: turn iojs.exe into iojs.dll, make new iojs.exe and node.exe as frontends for iojs.dll.
node_main.cc could become the new iojs executable target by itself and the rest of iojs would become libiojs, now dynamically link iojs to libiojs and have addons link to libiojs. Now addons would no longer be dependent on the name of the main executable.
kkoopa: +1. I think this should have happened long time ago and I think I have filled an issue related to this already. I'm interested if there is anything I can help with.
I have filled this one, which is related: nodejs/roadmap#9
- added a commit that references this issue
on Feb 8, 2015 Suggestion:
Adding a symbolic link in the iojs_install_path
node.exe <====> iojs.exe> cd iojs_install_path > mklink node.exe iojs.exe
For systems that node and iojs need to co-exists, additional work around is needed.
Prioritizing the iojs_install_path in the environmental PATH variable, when running iojs.exe. so it does not pick the original node binary on the system.Not sure if the suggestion will solve the issue @kkoopa reported.
Edit:
I noticed a case where a module build reference thenode.libin an external path ~/node-gyp
and not iojs_install_path where I assume the installation will place it.I experimented on node-sqlite3 which did not build for me out of the box.
The main issue was that it tried to reference ~.node-gyp\1.1.0\x64\node.lib, which does not exists.To resolve I added a symbolic link to the node.lib <== ==>iojs.lib in the proper ~.node-gyp path and patched node-sqlite3/package.json to support the 1.1.0 version.
The result is a successful build with iojs on windows.
For future references, nodejs/node-gyp#564 is an attempt to fix this problem on build tools' level.
This problem cannot be fixed from there. Addons have to register with the executable. If they depend on exports from iojs.exe, they cannot resolve them against node.exe and vice versa.
47 remaining items
- added a commit that references this issue
on Apr 24, 2015 - added 5 commits that reference this issue
on May 1, 2015 - added a commit that references this issue
on May 22, 2015 Is this still a issue?
It does still exist unfortunately. It still exists specifically for apps that statically link to node but have a different executable name, e.g. electron.exe, nw.exe, etc.
The delay load hook hack is a way to work around it. I have a PR out for
node-gypwhich would fix it automatically for everyone, I believe:
nodejs/node-gyp#653This would allow embedders to ship their own build of node.dll and automatically get compatibility with native modules compiled against node. Node would not have to ship a
node.dll, embedders could optionally do it to get compatibility.This won't be an issue in the converged 4.0.0 release. Since it's impractical to address in io.js (1.0.0> <4.0.0), I'm going to close this.
The node compatibility link is unusable on windows. Addons depend on doing a callback to the specified executable module via node_module_register, which is not possible when the name is wrong.
If an addon depends on iojs.exe, it cannot be used through node.exe and vice versa, giving the 'Module did not self-register.' error.