Building RAMTester in VC6

Im trying to build RAMTester in VC6 (Console app). I am linking in the okFrontPanel-vc6.lib library however I get loads of link errors which I cannot get rid of listed below. I cant see what im doing wrong here ?

Im not sure if this is the way im supposed to be doing it or not. Ive tried the dll method but with no success either. Can you use the dll with VS6 ?

Im going to be migrating to VS.Net 2005 in a month or so but need to get this going before then.

Link Errors:

svcprt.lib(MSVCP60.dll) : error LNK2005: “public: __thiscall std::basic_string,class std::allocator >::~basic_string,class std::allocator >(void)” (??1?$basic_string@
DU?$char_traits@D@std@@V?$allocator@D@2@@std@@QAE@XZ) already defined in MyRamTester.obj
msvcprt.lib(MSVCP60.dll) : error LNK2005: “public: class std::basic_string,class std::allocator > & __thiscall std::basic_string,class std::allocator >::assign(class s
td::basic_string,class std::allocator > const &,unsigned int,unsigned int)” (?assign@?$basic_string@DU?$char_traits@D@std@@V?$allocator@D@2@@std@@QAEAAV12@ABV12@II@Z) already defined in libcpd.lib(string.obj)
msvcprt.lib(MSVCP60.dll) : error LNK2005: “private: bool __thiscall std::basic_string,class std::allocator >::_Grow(unsigned int,bool)” (?_Grow@?$basic_string@DU?$char_traits@D@std@@V?$allocator@D@2@@std@@AAE
_NI_N@Z) already defined in MyRamTester.obj
msvcprt.lib(MSVCP60.dll) : error LNK2005: “private: void __thiscall std::basic_string,class std::allocator >::_Tidy(bool)” (?_Tidy@?$basic_string@DU?$char_traits@D@std@@V?$allocator@D@2@@std@@AAEX_N@Z) alread
y defined in MyRamTester.obj
msvcprt.lib(MSVCP60.dll) : error LNK2005: “public: class std::basic_string,class std::allocator > & __thiscall std::basic_string,class std::allocator >::erase(unsigned
int,unsigned int)” (?erase@?$basic_string@DU?$char_traits@D@std@@V?$allocator@D@2@@std@@QAEAAV12@II@Z) already defined in libcpd.lib(iostream.obj)
msvcprt.lib(MSVCP60.dll) : error LNK2005: “private: void __thiscall std::basic_string,class std::allocator >::_Eos(unsigned int)” (?_Eos@?$basic_string@DU?$char_traits@D@std@@V?$allocator@D@2@@std@@AAEXI@Z) a
lready defined in MyRamTester.obj
msvcprt.lib(MSVCP60.dll) : error LNK2005: “private: void __thiscall std::basic_string,class std::allocator >::_Split(void)” (?_Split@?$basic_string@DU?$char_traits@D@std@@V?$allocator@D@2@@std@@AAEXXZ) alread
y defined in libcpd.lib(iostream.obj)
msvcprt.lib(MSVCP60.dll) : error LNK2005: “void __cdecl std::_Xran(void)” (?_Xran@std@@YAXXZ) already defined in libcpd.lib(string.obj)
msvcprt.lib(MSVCP60.dll) : error LNK2005: “public: __thiscall std::basic_string,class std::allocator >::basic_string,class std::allocator >(class std::basic_string,class std::allocator > const &)” (??0?$basic_string@DU?$char_traits@D@std@@V?$allocator@D@2@@std@@QAE@ABV01@@Z) already defined in libcpd.lib(string.obj)
MSVCRT.lib(MSVCRT.dll) : error LNK2005: _memmove already defined in LIBCD.lib(memmove.obj)
MSVCRT.lib(MSVCRT.dll) : error LNK2005: __close already defined in LIBCD.lib(close.obj)
MSVCRT.lib(MSVCRT.dll) : error LNK2005: __lseek already defined in LIBCD.lib(lseek.obj)
LINK : warning LNK4098: defaultlib “MSVCRT” conflicts with use of other libs; use /NODEFAULTLIB:library
LINK : warning LNK4098: defaultlib “LIBCMT” conflicts with use of other libs; use /NODEFAULTLIB:library
Debug/MyRamTester.exe : fatal error LNK1169: one or more multiply defined symbols found
Error executing link.exe.

Ive got rid of most of my errors and warnings but now im just left with two warnings for LINK : warning LNK4098: defaultlib “MSVCRT” & “LIBCMT”

I have put these in the ignore library section but still get the error messages. However my exe still works fine so not really an issue at the moment but more of an anoyance. Im a bit concerned that this may cause a problem later.

These warnings may safely be ignored. You can alternatively tell VS to ignore those libraries. That will get rid of the warning.

However, I’d like to suggest that you use the DLL version of the API. Now that VS 2005 is released, VS6 is quite old. We will likely drop support for the “lib” versions and stick with the DLL.

The DLL is just as capable as the lib and is more portable across compilers and compiler versions.

I am going to move to VS 2005 very shortly and probably within the next few weeks. However I am slightly concerned by some of the other threads with people having trouble with VS 2005. Can you confirm if VS 2005 works properly with the DLL ? Im running on a fairly time critical project and cant really afford to run into any show stopping problems. Thanks.