Question

Any help much appreciated, my forehead’s getting bruised.

We have a big open source DICOM library (dcmtk) we use as a static lib. It’s unmanaged C++, and we’re linking to it from a managed C++ DLL that wraps it. It uses CMake to munge up the build instructions for various platforms. Moving to VS2010 (from 2008) broke our build, so we took the opportunity to update the library version we’re using as well (which should be more VS2010 friendly). After some screwing around the lib now builds (give or take a zillion warnings about type conversions). But now the code that uses it won’t link to it. It throws a bunch of unresolved external symbol errors.

It’s finding the library OK (if I change the lib filename it craps out earlier on w/ an appropriate msg).

If I disassemble the lib file with DUMPBIN I see the appropriate tokens, e.g.:
…
000000000000000E: C3 ret

??1OFString@@QEAA@XZ (public: __cdecl OFString::~OFString(void)):

0000000000000000: 40 53              push        rbx…

but the linker doesn’t find it:

error LNK2001: unresolved external symbol "public: __thiscall OFString::~OFString(void)" (??1OFString@@QAE@XZ)

I’ve been working the theory that it’s the __cdecl vs. __thiscall mismatch, but haven’t been able to get VS to build the lib with any other convention. (Ironically the old 2008 version, which does emit __thiscall, seems to be compiled with /Gd option that I thought forces __cdecl).

Any insights?

Answer 1

You can see the name mangling is different. Using undname.exe might help your cause:

Undecoration of :- "??1OFString@@QEAA@XZ"
is :- "public: __cdecl OFString::~OFString(void) __ptr64"

versus:

Undecoration of :- "??1OFString@@QAE@XZ"
is :- "public: __thiscall OFString::~OFString(void)"

Also, are you doing a mix of x64 and x86?