On Jul 13, 2010, at 12:47 PM, Thomas Volckhausen wrote:
> "Error 6 error LNK2005: "public: void __thiscall std::basic_string<char,struct
> std::char_traits<char>,class std::allocator<char> >::reserve(unsigned int)"
> (?reserve@?$basic_string@DU?$char_traits@D@std@@V?$allocator@D@2@@std@@QAEXI@Z<mailto:?reserve@?$basic_string@DU?$char_traits@D@std@@V?$allocator@D@2@@std@@QAEXI@Z>)
> already defined in Utility.obj
I'm thinking Utility.obj is one of your modules. It may be that it is built with
different settings than MySQL++. The VC++ linker is very sensitive about certain
settings; they have to match or it won't link. See README-Visual-C++.txt.
Other than that, the only known issue with VS2010 is that 64-bit builds don't work for
some reason. It's probably simple to fix, but no one's bothered to chase it down. The
shipping project files only build 32-bit libraries, so if you didn't do the 64-bit mod
described in the README, this isn't what's happening.
Note that this doesn't prevent you from using a 64-bit MySQL server.
> should I rebuild MySQL Server 5.1 from source in Visual Studio 2010
I don't think so.
> I know that linking across compilers can cause issues because of different naming
> conventions
That's pretty much only a problem with C++, due to differing name mangling rules between
compilers. The MySQL client library, being a pure C library, shouldn't suffer from this
problem.
