You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Hello, I want to use nodejs with swig. In order to do that I need to link my library with node.
But I cannot build shared library for nodejs only static (it's a requirement). So I build node js using this config ./configure --prefix=${NODEJS_INSTALL} --enable-static
So far everything build fine and smoothly, but when I link I have some missing symbol related to cache:
I am not sure what I am doing wrong, it seems this file can be autogenerated but not sure why is missing. I also try using whole archive when linking but change nothing.
Any thought ?
Version: v12.0.0
Platform: OSX
LINK ERROR :
Undefined symbols for architecture x86_64:
"node::native_module::has_code_cache", referenced from:
node::Initialize(v8::Localv8::Object, v8::Localv8::Value, v8::Localv8::Context) in libnode.a(node_config.o)
"node::native_module::NativeModuleEnv::InitializeCodeCache()", referenced from:
node::InitializeNodeWithArgs(std::__1::vector<std::__1::basic_string<char, std::__1::char_traits, std::__1::allocator >, std::__1::allocator<std::__1::basic_string<char, std::__1::char_traits, std::__1::allocator > > >, std::__1::vector<std::__1::basic_string<char, std::__1::char_traits, std::__1::allocator >, std::__1::allocator<std::__1::basic_string<char, std::__1::char_traits, std::__1::allocator > > >, std::__1::vector<std::__1::basic_string<char, std::__1::char_traits, std::__1::allocator >, std::__1::allocator<std::__1::basic_string<char, std::__1::char_traits, std::__1::allocator > > >*) in libnode.a(node.o)
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)
ninja: build stopped: subcommand failed.
Hello @wolfviking0 and @Cian-Chambliss, this is probably a bug (regression) introduced in #27161. Up until that change we used to link the code-cache symbols into the intermediary libnode target. But now we only link those into the final binary product.
P.S. as a workaround you could link your final binary with either the code cache stub (src/node_code_cache_stub.cc) or the full generated one (<(SHARED_INTERMEDIATE_DIR)/node_code_cache.cc)
@refack thanks, I used this approach initially in order to link, but because I am using node with swig I need to revert back to an older version of nodejs 10.15.3.
This version works fine.
Seeing the same linking errors with libnode (12.1.0) which is now in the Debian experimental branch.
Here the error appears when external software (in this case r-cran-v8) links to libnode.so. Hence the bug is not limited to static libraries as the topic suggests, but to anything trying to link to libnode that is not nodejs itself.
Also failing on Fedora Rawhide with R-V8, similarly to @jeroen on Debian, but using 12.4.0 (though I understand with this still being open, it's not been fixed yet.)
# 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 reason why the shared library is currently missing the code cache symbols is because of the cyclical dependency between libnode and mkcodecache in node.gyp.
We need mkcodecache to generate the cache symbols, but currently mkcodecache depends on libnode so we cannot include the generated symbols to libnode.
The solution is exactly as said in the comment above: modify the mkcodecache build such that it does not depend on the full libnode, but instead on a smaller libnode_base which suffices to generate the cache symbols. And then we can add those symbols when building the real libnode in a later step.
Activity
Cian-Chambliss commentedon Apr 27, 2019
I am running into the same error attempting to build with the dll option.
this occurs after running
vcbuild dll x86
refack commentedon Apr 27, 2019
Hello @wolfviking0 and @Cian-Chambliss, this is probably a bug (regression) introduced in #27161. Up until that change we used to link the code-cache symbols into the intermediary
libnodetarget. But now we only link those into the final binary product.I'm working on a fix.
refack commentedon Apr 27, 2019
P.S. as a workaround you could link your final binary with either the code cache stub (
src/node_code_cache_stub.cc) or the full generated one (<(SHARED_INTERMEDIATE_DIR)/node_code_cache.cc)wolfviking0 commentedon Apr 27, 2019
@refack thanks, I used this approach initially in order to link, but because I am using node with swig I need to revert back to an older version of nodejs 10.15.3.
This version works fine.
Cian-Chambliss commentedon Apr 28, 2019
Thanks, adding node_code_cache.cc as you suggested to the nodelib.vcxproj fixed that project.
jeroen commentedon Jun 12, 2019
Seeing the same linking errors with libnode (12.1.0) which is now in the Debian experimental branch.
Here the error appears when external software (in this case
r-cran-v8) links tolibnode.so. Hence the bug is not limited to static libraries as the topic suggests, but to anything trying to link to libnode that is not nodejs itself.QuLogic commentedon Jun 21, 2019
Also failing on Fedora Rawhide with
R-V8, similarly to @jeroen on Debian, but using 12.4.0 (though I understand with this still being open, it's not been fixed yet.)jeroen commentedon Jul 26, 2019
Is there anyone who can take a look at this? This is blocking node 12 on Fedora and Debian now.
jeroen commentedon Jul 29, 2019
@joyeecheung I tried to patch this but I realized we probably need to fix this:
node/node.gyp
Lines 1161 to 1166 in 62a809f
The reason why the shared library is currently missing the code cache symbols is because of the cyclical dependency between
libnodeandmkcodecachein node.gyp.We need
mkcodecacheto generate the cache symbols, but currentlymkcodecachedepends onlibnodeso we cannot include the generated symbols tolibnode.The solution is exactly as said in the comment above: modify the
mkcodecachebuild such that it does not depend on the fulllibnode, but instead on a smallerlibnode_basewhich suffices to generate the cache symbols. And then we can add those symbols when building the reallibnodein a later step.build: include stubs in shared library
build: include stubs in shared library