Build static libnode_internal to avoid cyclic dependency on mkcodecache

[jeroen]

Here is a first draft to fix #27431 by implementing exactly this:

node/node.gyp

Lines 1161 to 1166 in 62a809f

	# TODO(joyeecheung): do not depend on node_lib,
	# instead create a smaller static library node_lib_base that does
	# just enough for node_native_module.cc and the cache builder to
	# compile without compiling the generated code cache C++ file.
	# So generate_code_cache -> mkcodecache -> node_lib_base,
	# node_lib -> node_lib_base & generate_code_cache

The problem here is that the libnode shared library is missing the code cache symbols because of the cyclical dependency between libnode and mkcodecache in node.gyp.

We need to build mkcodecache to generate node_code_cache.cc. However currently mkcodecache itself depends on libnode so we cannot include the generated symbols to libnode. In the current setup node_code_cache.cc is linked when building node.exe but when building node as a shared library the symbols are missing libnode, which causes the issues in #27431.

The solution is described comment above: modify the mkcodecache build such that it does not depend on the full libnode, but instead on a smaller libnode_internal which suffices to generate the cache symbols. And then we can include node_code_cache.cc in libnode.so.

Checklist

• make -j4 test (UNIX), or vcbuild test (Windows) passes
• tests and/or benchmarks are included
• documentation is changed or added
• commit message follows commit guidelines

[Trott]

@nodejs/node-gyp @joyeecheung

[devsnek]

is this list duplicated now?

[Trott]

Pinging some other folks that I suspect might have opinions: @indutny @addaleax @jasnell @danbev

[jeroen]

The bug #27431 has already been fixed via a more simple solution in #28897.

Ideally a rewrite of the build as above would probably be better so that we get the same cached symbols when calling libnode from a 3rd party application as in node itself. However this is just a small performance gain and for my purposes the workaround from #28897 suffices.