0

Feel free to edit the title: I honestly dont know what is the important info for this question...

I am seeing some very strange missing symbols when linking an app (built against gRPC and Kinect10 SDK, ptr type is defined in gRPC static lib if that matters), but only when using std::unique_ptr. I'm not actually using the ptr at all (yet), but if I convert to a native ptr it gives no error.

Why might this be happening? I am compiling in VS2015 x64

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

1>libeay32.lib(rand_win.obj) : error LNK2019: unresolved external symbol __imp_CreateCompatibleBitmap referenced in function readscreen 1>libeay32.lib(rand_win.obj) : error LNK2019: unresolved external symbol __imp_DeleteObject referenced in function readscreen 1>libeay32.lib(rand_win.obj) : error LNK2019: unresolved external symbol __imp_GetDeviceCaps referenced in function readscreen 1>libeay32.lib(rand_win.obj) : error LNK2019: unresolved external symbol __imp_GetDIBits referenced in function readscreen 1>libeay32.lib(rand_win.obj) : error LNK2019: unresolved external symbol __imp_GetObjectW referenced in function readscreen

if I reverse the declaration, the errors go away

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

========== Build: 1 succeeded, 0 failed, 0 up-to-date, 0 skipped ==========

Whats also strange is the errors themselves - these errors come from within a build of gRPC. I link to the static libs, so obviously I could just be missing linking to another lib (if the unique_ptr thing turns out to make sense) - but I couldn't imagine why gRPC would be calling getDIBits? Does this make any sense (note - I haven't read the source code to verify, it just seems weird). Is it possible that the libraries I have linked together may be confusing each other? Possibly by collisions between names/fn definitions, or anything?

FrozenKiwi
  • 1,362
  • 13
  • 26

1 Answers1

2

Why unique_ptr gives different results from raw pointer? Because unique_ptr specialization includes a call to grpc::~Server destructor whereas raw pointer doesn't. Linker can drop unused files (or even single function) from the binary so if destructor called some unresolved references they might not come up if destructor is optimized out. Where these GDI calls come from? Actual error comes from OpenSSl; my guess would be gRPC uses openssl for https access, and openssl in turns uses screengrabs to generate some randomness. EDIT: and I realized that this explanation didn't help with an issue at hand. So, to fix that you just need to link with gdi32.dll

Andrey Turkin
  • 1,787
  • 9
  • 18