Destructor Bug
I've got a problem: my VS6.0 C++ project won't build in Release mode. It complains about the destructor of a class declared in another DLL:
So I look in the offending DLL with Depends.exe, and I find that the mangled name for the destructor differs by one character:
The U stands for virtual. The DLL that exports the symbol is a Debug DLL and the one importing is a Release DLL. So, why is the Release DLL looking for the non-vitual version of the exported class' destructor?
It turns out that whoever implemented the class pulled one of those #ifdef _DEBUG stunts. In Debug mode our imported class is given a base class, while in Release mode it's not.
By default, the VS6.0 compiler declares the destructor as virtual if the class has a base class, but does not otherwise.
So, by explicitly declaring the destructor as virtual (which is always a good idea) we restore Debug/Release binary compatibility.
HEADTRL.OBJ : error LNK2001: unresolved external symbol "public: __thiscall TCIOControl::~TCIOControl(void)" (??1TCIOControl@@QAE@XZ)
So I look in the offending DLL with Depends.exe, and I find that the mangled name for the destructor differs by one character:
??1TCIOControl@@UAE@XZ
The U stands for virtual. The DLL that exports the symbol is a Debug DLL and the one importing is a Release DLL. So, why is the Release DLL looking for the non-vitual version of the exported class' destructor?
It turns out that whoever implemented the class pulled one of those #ifdef _DEBUG stunts. In Debug mode our imported class is given a base class, while in Release mode it's not.
By default, the VS6.0 compiler declares the destructor as virtual if the class has a base class, but does not otherwise.
So, by explicitly declaring the destructor as virtual (which is always a good idea) we restore Debug/Release binary compatibility.
0 Comments:
Post a Comment
<< Home