v14.6.0 dll build error

[Reveares]

• Version: 14.6.0
• Platform: 64-bit Windows 10
• Subsystem:

What steps will reproduce the bug?

Build Node 14.6.0 as 64-bit and shared linkage under windows. Meanwhile static linkage works fine for me.

.\vcbuild.bat dll

Results in:

      Creating library out\Release\libnode.lib and object out\Release\libnode.exp
v8_libbase.lib(platform-win32.obj) : error LNK2019: unresolved external symbol __imp_timeGetTime referenced in function "public: void __cdecl v8::base::Win32Time::SetToCurrentTime(void)" (?SetToCurrentTime@Win32Time@base@v8@@QEAAXXZ) [C:\Users\janek\source\repos\node-14.6.0\libnode.vcxproj]
v8_libbase.lib(time.obj) : error LNK2001: unresolved external symbol __imp_timeGetTime [C:\Users\janek\source\repos\node-14.6.0\libnode.vcxproj]
out\Release\libnode.dll : fatal error LNK1120: 1 unresolved externals [C:\Users\janek\source\repos\node-14.6.0\libnode.vcxproj]

[bnoordhuis]

That function lives in winmm.lib and that library is linked in, as far as I'm aware. Long shot but does this patch help?

diff --git a/tools/v8_gypfiles/v8.gyp b/tools/v8_gypfiles/v8.gyp
index f8259069c9..7a51ec9b54 100644
--- a/tools/v8_gypfiles/v8.gyp
+++ b/tools/v8_gypfiles/v8.gyp
@@ -1093,6 +1093,15 @@
             'defines': ['_WIN32_WINNT=0x0602'], # For GetCurrentThreadStackLimits on Windows on Arm
           }]],
           'defines': ['_CRT_RAND_S'], # for rand_s()
+          'msvs_settings': {
+            'VCLinkerTool': {
+              'AdditionalDependencies': [
+                'dbghelp.lib',
+                'winmm.lib',
+                'ws2_32.lib'
+              ]
+            }
+          },
           'direct_dependent_settings': {
             'msvs_settings': {
               'VCLinkerTool': {

[Reveares]

I applied your diff but unfortunately the problem still remains the same.

[bnoordhuis]

I'm fairly sure other people build the DLL without problems (it might even be tested by our CI, I'm not sure) so it's probably an issue local to your system.

I don't have concrete suggestions on how to fix it. You'll probably have to go over the *.gyp and *.gypi files and judiciously add/update link sections. There are quite a few build files but node.gyp/node.gypi and the V8 *.gyp files are the most relevant ones.

[Reveares]

I believe too there are people that build the dll. So I did a fresh install of Windows 10 and installed only git, Python 3.8, Visual Studio Community 2019 with the C++ workload and downloaded Node.js 14.6.0 from the release tab on Github. But it resulted in the same error.
Maybe there is a problem with newer Visual Studio versions? I don't know, would be interesting to know the build setup from others.
By times I will check the build files.

[bzoz]

Can reproduce. Also - I can't find a revision that would build the dll successfully, so it looks this is broken for some time now.

/cc @nodejs/platform-windows @nodejs/build-files

[bzoz]

Using this patch:

diff --git a/node.gyp b/node.gyp
index 6dd9541cc5..302e9ba269 100644
--- a/node.gyp
+++ b/node.gyp
@@ -823,6 +823,7 @@
             'Dbghelp',
             'Psapi',
             'Ws2_32',
+            'Winmm'
           ],
         }],
         [ 'node_use_etw=="true"', {

will fix this linking error, but it will open another can of worms:

v8_base_without_compiler.lib(basic-block-profiler.obj) : error LNK2005: "public: static class v8::internal::BasicBlockProfiler * __cdecl v8::internal::BasicBlockProfiler::Get(void)" (?Get@BasicBlockProfiler@internal@v8@@SAPEAV123@XZ) already defined in libnode.lib(libnode.dll) [C:\...\node\node.vcxproj]
v8_base_without_compiler.lib(machine-type.obj) : error LNK2005: "class std::basic_ostream<char,struct std::char_traits<char> > & __cdecl v8::internal::operator<<(class std::basic_ostream<char,struct std::char_traits<char> > &,class v8::internal::MachineType)" (??6internal@v8@@YAAEAV?$basic_ostream@DU?$char_traits@D@std@@@std@@AEAV23@VMachineType@01@@Z) already defined in libnode.lib(libnode.dll) [C:\...\node\node.vcxproj]
v8_base_without_compiler.lib(machine-type.obj) : error LNK2005: "class std::basic_ostream<char,struct std::char_traits<char> > & __cdecl v8::internal::operator<<(class std::basic_ostream<char,struct std::char_traits<char> > &,enum v8::internal::MachineRepresentation)" (??6internal@v8@@YAAEAV?$basic_ostream@DU?$char_traits@D@std@@@std@@AEAV23@W4MachineRepresentation@01@@Z) already defined in libnode.lib(libnode.dll) [C:\...\node\node.vcxproj]
v8_base_without_compiler.lib(machine-type.obj) : error LNK2005: "char const * __cdecl v8::internal::MachineReprToString(enum v8::internal::MachineRepresentation)" (?MachineReprToString@internal@v8@@YAPEBDW4MachineRepresentation@12@@Z) already defined in libnode.lib(libnode.dll) [C:\...\node\node.vcxproj]

the libnode.dll will be there, but the build script will fail to build node.exe

[bzoz]

Oh, and manually removing v8_base_without_compiler from node References in VS solves this.

[mikeseese]

I had to do the following once I found this issue:

1. Apply @bzoz's patch to node.gyp
2. .\vcbuild.bat clean
3. .\vcbuild.bat dll
4. Get other linker errors, open the SLN file, remove the v8_base_without_compiler from References under the node project also mentioned by @bzoz
5. .\vcbuild.bat dll noprojgen (note the noprojgen! without this, it just regenerated the VS projects)

Thanks @bzoz for the help!

[jianweiqin]

@Reveares @bzoz @seesemichaelj
Hello, everyone! I seem to get the libnode.dll successfully with @bzoz and @seesemichaelj 's comments. But I really want to know what that dll file is. Is it a file that can be used by an .exe file to run a .js file? If so, could you tell me how to use it? What are the export functions? Where can I get the document of it? Thank you!

[mikeseese]

@jianweiqin libnode.dll allows you to embed a NodeJS runtime in your executables. This allows you to either use the C++ bindings to call functionality directly or pass a string of JS to compile and run. I could not find any official documentation or meaningful examples on how to use it in the general sense. I spent quite a bit of time reverse engineering and piecing together how to get it to work for my use case. I spent a lot of time in the debugger, reading how to use the V8 C++ bindings, and looking at the test suites at https://github.com/nodejs/node/tree/master/test. I don't believe using libnode.dll is really a "supported" feature.

Unfortunately, I don't currently have the time to pull out the proprietary pieces of the code I've gotten working for a publicly distributable example. I'm guessing I won't have the time any time soon. I can however maybe give you a couple of quick function references for initialization:

1. Initialize node and create a platform:

  std::vector<std::string> args = { "SomeArbitaryStringIGuess" };
  std::vector<std::string> exec_args;
  std::vector<std::string> errors;
  if (!node::NodeIsInitialized()) {
    exit_code = node::InitializeNodeWithArgs(&args, &exec_args, &errors);
    ...
    
    this->platform = node::CreatePlatform(4, (v8::TracingController *) nullptr);
    v8::V8::InitializePlatform(this->platform);
    v8::V8::Initialize();
  } else {
    this->platform = (node::MultiIsolatePlatform*) v8::V8::GetCurrentPlatform();
  }

1. Create/initialize UV uv_loop_init(...)
2. Create an isolate node::NewIsolate(...)
3. Create Isolate Data node::CreateIsolateData (requires creating an v8::Locker, v8::Isolate::Scope, and ve::HandleScope all bundled in a C99 scope
4. Create a new context node::NewContext(isolate)
5. Create a node environment node::CreateEnvironment
6. Load the node environment node::LoadEnvironment

There's a lot of minor details missing from this, but this should give you some indicator of source files to dig through and determine the solution on your own. Best of luck!

[shockdev04]

Still happening in

16.13.0

[FishOrBear]

** seesemichaelj**

https://www.electronjs.org/blog/electron-internals-node-integration
For example:electron

[Developer-Alexander]

• Setting environment variable _LINK_ to "winmm.lib" fixed it for me for node v16.14.0.

Alternatively:

• Add winmm.lib as linker input file to project libnode in Visual Studio.

Note: It seems to work for Visual Studio 2019 toolchain but not for 2022)

[DavidPeicho]

Any chance the build system could be fixed upstream for Windows?

EDIT: I actually think it's fixed and non of that is needed anymore

[bnoordhuis]

I'm indeed fairly sure it's fixed (also in v14.x) and that we simply forgot to close this issue so I'll go ahead and do that now.