斯特兰奇的缺失导入符号“时使用的std ::的unique_ptr

Question

随意编辑标题：老实说，我不知道什么是对这个问题的重要信息...

我看到一些很奇怪链接应用程序时缺少符号（针对gRPC和Kinect10 SDK构建，ptr类型在gRPC静态库中定义，如果重要的话），但仅在使用std :: unique_ptr时使用。我根本没有使用ptr（但是），但是如果我转换为本地ptr，它不会出现任何错误。

为什么会发生这种情况？我在VS2015 64编译

std::unique_ptr<grpc::Server> m_server; 
//grpc::Server* m_server; 

1> libeay32.lib（rand_win.obj）：错误LNK2019：解析外部符号__imp_CreateCompatibleBitmap在函数引用readscreen 1> libeay32.lib（rand_win.obj）：错误LNK2019 ：无法解析的外部符号__imp_DeleteObject在函数中引用 1> libeay32.lib（rand_win.obj）：error LNK2019：无法解析的外部符号__imp_GetDeviceCaps在函数读取屏幕中引用 1> libeay32.lib（rand_win.obj）：error LNK2019：无法解析的外部符号__imp_GetDIBits函数读取屏幕引用 1> libeay32.lib（rand_win.obj）：错误LNK2019：无法解析的外部符号__imp_GetObject在功能readscreenW¯¯引用

，如果我扭转声明，错误消失

//std::unique_ptr<grpc::Server> m_server; 
grpc::Server* m_server; 

==========生成：1成功，0失败，0先进-date，0 skip ==========

还有一点奇怪的是错误本身 - 这些错误来自于gRPC构建。我链接到静态库，所以很明显，我可能会错过链接到另一个库（如果unique_ptr事情变得有意义） - 但我无法想象为什么gRPC会调用getDIBits？这是否有意义（注意 - 我没有阅读源代码来验证，这似乎很奇怪）。我连接在一起的图书馆可能会混淆对方吗？可能是由名称/ fn定义之间的冲突，还是任何事情？

Answer 1

为什么unique_ptr从原始指针给出不同的结果？因为unique_ptr特化包括对grpc ::〜Server析构函数的调用，而原始指针不包含。链接器可以从二进制文件中删除未使用的文件（甚至单个函数），所以如果析构函数调用了一些未解析的引用，那么如果析构函数被优化，它们可能不会出现。 这些GDI呼叫来自哪里？实际的错误来自OpenSSl;我的猜测是gRPC使用openssl进行https访问，而openssl轮流使用screengrabs产生一些随机性。编辑：我意识到这个解释并没有帮助解决手头的问题。所以，要解决这个问题，你只需要链接gdi32.dll