我试图使用node-gyp
链接一个静态库,以便将其用作原生node
插件。但是,当我运行node-gyp rebuild
时,我得到以下链接错误:
error LNK2001: unresolved external symbol "double __cdecl mylibengine::criticalZvalue(double)" (?criticalZvalue@mylibengine@@YANN@Z)
紧接着是:
C:\Users\Mihai\Desktop\msp-addon\build\Release\mylib-addon.node : fatal error LNK1120: 1 unresolved externals [C:\Users\Mihai\Desktop\mylib-addon\build\mylib-addon.vcxproj
binding.gyp
看起来像:
{
'targets': [{
'target_name': 'mylib-addon',
'cflags!': [ '-fno-exceptions' ],
'cflags_cc!': [ '-fno-exceptions' ],
'include_dirs': [
'<!@(node -p \"require(\'node-addon-api\').include\")',
'<(module_root_dir)/dependencies/mylib/include/'
],
'sources': [
'src/MyLibNode.cpp'
],
'dependencies': [
'<!(node -p \"require(\'node-addon-api\').gyp\")'
],
'libraries': [
'<(module_root_dir)/dependencies/mylib/lib/x64/libmylib.a'
],
'defines': [ 'NAPI_DISABLE_CPP_EXCEPTIONS' ]
}]
}
MyLibNode.cpp
看起来像这样:
#include <napi.h>
#include "engine.h"
Napi::Object InitAll(Napi::Env env, Napi::Object exports)
{
// Temporary check to make sure `libmylib.a` works.
mylibengine::criticalZvalue(.3);
return exports;
}
NODE_API_MODULE(mspaddon, InitAll)
我确信链接器可以找到libmylib.a
,因为当我更改库的名称(例如,更改为disabled.a
)时,我会得到一个不同的错误,说输入文件无法打开。但是,它 * 无法解析外部符号 *。
我发现了一个类似的,未回答的问题here。对其他问题的回答表明要将完整的库路径添加到libraries
,但我不认为这是我的场景的问题。
为什么node-gyp
不能解析外部符号?
补充信息:
- 我正在运行Windows 10
- 我通过尝试将该库与
g++
一起使用来测试该库是否正常工作,如下所述
我的项目结构如下:
├───build
└───dependencies
└───mylib
├───include
└───lib
└───x64
- 在
dependencies/mylib/include
中,我有一个名为engine.h
的头文件,其中包含:
#pragma once
namespace mylibengine
{
double criticalZvalue(double quantile);
}
- 在
dependencies/mylib/lib/x64
中,我有一个名为libmylib.a
的静态库 - 在根目录中,我有一个名为
main.cpp
的文件,其中包含:
#include <iostream>
#include <engine.h>
int main()
{
std::cout << "Main working." << "\n";
std::cout << mylibengine::criticalZvalue(.3) << "\n";
}
我可以在可执行文件中链接库:
g++ -obuild/main main.cpp -Idependencies/mylib/include/ -Ldependencies/mylib/lib/x64/ -lmylib
此时,运行main.exe
将输出正确的结果:
Main working.
-0.524002
1条答案
按热度按时间okxuctiv1#
在上面的问题中,静态库
libmylib.a
是使用mingw64
安装中的g++
编译的。但是,node-gyp
使用Microsoft C和C++(MSVC)运行时库。node-gyp
似乎不支持mingw64
(参见this issue on GitHub)。在链接的问题中,有人表示mingw使用自己的名称管理方案,使得互操作性变得不可能。
这也是本问题中遇到的问题(即
error LNK2001: unresolved external symbol
)。解决方案是使用Microsoft工具链创建静态库,然后链接器将正确解析符号。