随意编辑标题：老实说，我不知道这个问题的重要信息是什么......
我在链接应用程序时看到一些非常奇怪的缺失符号（根据gRPC和Kinect10 SDK构建，ptr类型在gRPC静态库中定义，如果这很重要），但仅在使用std :: unique_ptr时。我根本没有实际使用ptr，但如果我转换为原生ptr它没有错误。
为什么会发生这种情况？我正在编译VS2015 x64
std::unique_ptr<grpc::Server> m_server;
//grpc::Server* m_server;
1＆gt; libeay32.lib（rand_win.obj）：错误LNK2019：函数readscreen中引用的未解析的外部符号__imp_CreateCompatibleBitmap 1＆gt; libeay32.lib（rand_win.obj）：错误LNK2019：函数readscreen中引用的未解析的外部符号__imp_DeleteObject 1＆gt; libeay32.lib（rand_win.obj）：错误LNK2019：函数readscreen中引用的未解析的外部符号__imp_GetDeviceCaps 1＆gt; libeay32.lib（rand_win.obj）：错误LNK2019：函数readscreen中引用的未解析的外部符号__imp_GetDIBits 1＆gt; libeay32.lib（rand_win.obj）：错误LNK2019：函数readscreen中引用的未解析的外部符号__imp_GetObjectW
如果我撤销声明，错误就会消失
//std::unique_ptr<grpc::Server> m_server;
grpc::Server* m_server;
==========构建：1成功，0失败，0最新，0跳过==========
错误本身也很奇怪 - 这些错误来自gRPC的构建。我链接到静态库，所以很明显我可能只是缺少链接到另一个lib（如果unique_ptr事情变得有意义） - 但我无法想象为什么gRPC会调用getDIBits？这有什么意义吗（注意 - 我还没有读过要验证的源代码，这看起来很奇怪）。我联系在一起的图书馆可能会互相混淆吗？可能是名称/ fn定义之间的冲突，还是其他什么？
答案 0 :(得分：1)
为什么unique_ptr会给出原始指针的不同结果？因为unique_ptr特化包括对grpc :: ~Server析构函数的调用，而原始指针不包含。链接器可以从二进制文件中删除未使用的文件（甚至单个函数），因此如果析构函数调用了一些未解析的引用，则如果析构函数被优化，它们可能不会出现。 这些GDI呼叫来自哪里？实际错误来自OpenSSl;我的猜测是gRPC使用openssl进行https访问，而openssl依次使用screengrabs来生成一些随机性。 编辑：我意识到这个解释对手头的问题没有帮助。所以，要修复你只需要链接gdi32.dll