views:

265

answers:

1

I am getting this linker error when trying to compile the c++ project for the VSS SDK

Error   1 error LNK2019: unresolved external symbol "long __stdcall ShouldBlockRevert(wchar_t const *,bool *)" (?ShouldBlockRevert@@YGJPB_WPA_N@Z) referenced in function "public: void __thiscall VssClient::RevertToSnapshot(struct _GUID)" (?RevertToSnapshot@VssClient@@QAEXU_GUID@@@Z) revert.obj vshadow

The ShouldBlockRevert is used twice, once when it is declared at the top, and once when it is actually used.

Declared here:

HRESULT APIENTRY ShouldBlockRevert(IN LPCWSTR wszVolumeName, OUT bool* pbBlock);

and used here:

CHECK_COM(::ShouldBlockRevert(Snap.m_pwszOriginalVolumeName, &bBlock));
    if (bBlock)
    {
        ft.WriteLine(L"Revert is disabled on the volume %s because of writers",
                Snap.m_pwszOriginalVolumeName);
        return;
    }

Sorry, I'm not that good with c++.

+1  A: 

According to this blog post:

As it happens, I ran dumpbin /exports on vssapi.lib, and found that it does export ShouldBlockRevert, but thanks to C++ name mangling the mangled name is different. Why is it different? Because in vssapi.lib, the first argument to ShouldBlockRevert isn’t wchar_t, it’s unsigned short. “So what”, you’re thinking, “they’re equivalent”. And I don’t disagree, but the compiler treats them as different types for name manging purposes. What’s the fix? Well, disable the intrinsic wchar_t type in the C/C++ Language property page in the project properties (equivalent to the /Zc:wchar_t- switch if you’re one of the two people on the planet who build Visual C++ projects with makefiles).

Once that’s done, the LPCWSTR macro is defined to unsigned short, name mangling matches, planets align, and you can link. QED.

dirkgently
nope, already done that. It came set up.
Malfist
Are you on Vista?
dirkgently
See updated answer.
dirkgently
ah, error went away when I switched the configuration to debug-xp instead of debug-server
Malfist
Most probably the configurations have a difference in how they treat wchar_t. Can you confirm?
dirkgently
that fixed it, thanks!
Malfist
no, the xp version treated wchar_t the same as the server version. odd...
Malfist
Then you may not be using this function in debug-server.
dirkgently