Greetings.
I’m using the IFS Kit to write a file system minifilter driver. I’ve
been incorporating some C++ routines into it, and things work great
until I use the string class of the STL. Then, as soon as I have a
class that implies a destructor of a string, the linker explodes.
Here’s the tail of the output of NMAKE:
C:\WINDDK\3790~1.183\lib\wxp\i386\BufferOverflowU.lib
C:\WINDDK\3790~1.183\lib\crt\i386\msvcrt.lib
C:\WINDDK\3790~1.183\lib\wxp\i386\advapi32.lib
C:\WINDDK\3790~1.183\lib\wxp\i386\kernel32.lib
C:\WINDDK\3790~1.183\lib\wxp\i386\fltLib.lib
C:\WINDDK\3790~1.183\lib\wxp\i386\sehupd.lib
C:\WINDDK\3790~1.183\lib\wxp\i386\shell32.lib
widget.obj : error LNK2019: unresolved external symbol
“__declspec(dllimport) public: __thiscall
std::basic_string,class
std::allocator >::~basic_stringstd::char_traits,class std::allocator >(void)”
(_imp??1?$basic_string@DU?$xxxxx@xxxxx@std@@V?$allocator@D@2@@std@@
QAE@XZ)
referenced in function “public: void__thiscall Fred::dump(class
std::basic_string,class
std::allocator > const &)const “
(?xxxxx@Fred@@QBEXABV?$basic_string@DU?$xxxxx@xxxxx@std@@V?$allocator@D
@2@@std@@@Z)
widget.obj : error LNK2019: unresolved external symbol
”__declspec(dllimport) public:__thiscall
std::basic_string,class
std::allocator >::basic_stringstd::char_traits,class std::allocator >(class
std::basic_string,class
std::allocator > const &)”
(_imp??0?$basic_string@DU?$xxxxx@xxxxx@std@@V?$allocator@D@2@@std@@
xxxxx@ABV01@@Z)
referenced in function "public: void__thiscall Fred::dump(class
std::basic_string,class
std::allocator > const &)const "
(?xxxxx@Fred@@QBEXABV?$basic_string@DU?$xxxxx@xxxxx@std@@V?$allocator@D
@2@@std@@@Z)
objfre_wxp_x86\i386\analysis.exe : fatal error LNK1120: 2 unresolved
externals
NMAKE : fatal error U1077: ‘link’ : return code ‘0x460’
Stop.
From what I’ve read by googling for ‘LNK2019 basic_string’, this
happens when my libraries have version mismatches, such as the libs
being built with MSVC 6 and the code with MSVC 7, due to changes in
the structure of basic_string in Microsoft’s implementation. The
solution for this is to “rebuild your libraries.”
But I’m using the default IFS Kit. This is on Win XP SP2, and I
selected the “Windows XP Free Build Environment” from the start
menu. Even if I could somehow rebuild Microsoft’s libraries, I
don’t understand how there could be a mismatch, since my binaries
and my libraries are all from the same development kit.
I do have other development environments on this machine, but the
previous DDK was fully uninstalled before the IFS was installed, and I
have verified that the “Windows XP Free Build Environment” is only
using things in C:\WINDDK\3790.1830 for includes and libraries. (I
even placed an “#error 1” in the inc\crt\string file underneath the
above directory and compilation aborted like one would expect.) And
I’ve compared version numbers for both CL.EXE and LINK.EXE (13.10.4035
and 7.10.4035, if it matters.)
I saw Microsoft’s KB article Q309801 and tried using explicit template
instantiations as they hinted at, by adding these lines:
template class __declspec(dllimport) std::basic_string std::char_traits, class std::allocator >;
but that had no change whatsoever on the results.
I’ve tried using many of the other deveopment shells and doing clean
builds with them, but that had no effect (besides changing the path of
the libraries being used).
What next steps should I take to figure out my problem?
). I had these same problems