CryptAcquireContext -- unresolved external

Question

I'm linking with a third-party library (Poco C++) and getting the following unresolved symbol errors from the linker. It appears to be unable to find "CryptAcquireContextW", "CryptReleaseContext", and "CryptGenRandom".

According to the Microsoft information here, these functions are linkable using "Advapi32.lib". I've added that to my linker inputs but the symbols remain unresolved.

1>PocoFoundationCLR.lib(RandomStream.obj) : error LNK2019: unresolved external symbol __imp__CryptAcquireContextW@20 referenced in function "public: virtual int __thiscall Poco::RandomBuf::readFromDevice(char *,__int64)" (?readFromDevice@RandomBuf@Poco@@UAEHPAD_J@Z)

1>PocoFoundationCLR.lib(RandomStream.obj) : error LNK2019: unresolved external symbol __imp__CryptReleaseContext@8 referenced in function "public: virtual int __thiscall Poco::RandomBuf::readFromDevice(char *,__int64)" (?readFromDevice@RandomBuf@Poco@@UAEHPAD_J@Z)

1>PocoFoundationCLR.lib(RandomStream.obj) : error LNK2019: unresolved external symbol __imp__CryptGenRandom@12 referenced in function "public: virtual int __thiscall Poco::RandomBuf::readFromDevice(char *,__int64)" (?readFromDevice@RandomBuf@Poco@@UAEHPAD_J@Z)

I've verified that Advapi32.lib is on the search path and Advapi32.dll is in the Windows directory, so I'm not sure how this error continues to happen.

Ideas, anyone?

Thanks!

Twerp

I just tried calling CryptReleaseContext from Visual Studio 2010, and advapi32.lib was necessary and sufficient to make it link successfully. Perhaps you should double-check that advapi32.lib really is being specified on the linker's command line? (Oh, and that it is the correct bitness.) – Turgent

Try linking with Crypt32.lib – Milissa

Thanks, guys. I have new info. I am able to build fine on my personal PC with VS 2013 Professional using only Advapi32.lib in the linker input line. But the PC where it fails is using VS 2013 Community Edition. Is it possible Advapi32.lib is only available with the Pro edition? That doesn't make a ton of sense, but it's the only real difference between the PCs. – Twerp

Try installing the SDK, and changing the project settings to use it rather than the version included with Visual Studio. – Turgent

I tried that, but adding an SDK path to the system caused a ton of duplicate symbols and header issues. I'd probably need to revamp the project files significantly to make this work. Luckily this time I skated by without needing to do so. :-) – Twerp

Answer 1

Although I can't readily explain why this worked, here's what did.

The project that was failing had "Advapi32.lib" listed in the "Inherited" section of the linker inputs, but apparently wasn't actually being linked in.

I added "Advapi32.lib" to the "additional libraries" section and somehow that caused it to be picked up and linked with properly.

I'm going to write it off as just a difference in how VS 2013 was installed on the two PCs, but it's still a curious oddity.

Twerp