Unresolved symbols with mysqlclient in DEBUG mode using VC++ 2010 Express
Hello friends I'm back to MySQL programming using the C API... it works fine when I compile using the RELEASE mode and C:\Program Files (x86)\MySQL\MySQL Server 5.5\lib but if I choose the DEBUG mode and C:\Program Files (x86)\MySQL\MySQL Server 5.5\lib\debug it fails at link time: 1mysqlclient.lib(dbug.obj) : error LNK2019: unresolved external symbol __CrtSetReportFile referenced in function _DbugExit 1mysqlclient.lib(my_init.obj) : error LNK2001: unresolved external symbol __CrtSetReportFile 1mysqlclient.lib(dbug.obj) : error LNK2019: unresolved external symbol __CrtSetReportMode referenced in function _DbugExit 1mysqlclient.lib(my_init.obj) : error LNK2001: unresolved external symbol __CrtSetReportMode 1mysqlclient.lib(my_init.obj) : error LNK2019: unresolved external symbol __CrtDumpMemoryLeaks referenced in function _my_end 1mysqlclient.lib(my_init.obj) : error LNK2019: unresolved external symbol __CrtCheckMemory referenced in function _my_end I read some posts that found in google about this error and found that it should be used the dynamic library libmysql instead of the static mysqlclient when debugging, but the lib\debug directory contains just the static library mysqlclient... Do I have to include an aditional library so the symbols are resolved correctly? The release mode works perfect and the application runs fine in that way only... Thanks, Miguel -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe:http://lists.mysql.com/mysql
Re: Unresolved symbols with mysqlclient in DEBUG mode using VC++ 2010 Express
On Tue, Jun 19, 2012 at 2:48 AM, Miguel Cardenas renit...@gmail.com wrote: Hello friends 1mysqlclient.lib(dbug.obj) : error LNK2019: unresolved external symbol __CrtSetReportFile referenced in function _DbugExit 1mysqlclient.lib(my_init.obj) : error LNK2001: unresolved external symbol __CrtSetReportFile 1mysqlclient.lib(dbug.obj) : error LNK2019: unresolved external symbol __CrtSetReportMode referenced in function _DbugExit 1mysqlclient.lib(my_init.obj) : error LNK2001: unresolved external symbol __CrtSetReportMode 1mysqlclient.lib(my_init.obj) : error LNK2019: unresolved external symbol __CrtDumpMemoryLeaks referenced in function _my_end 1mysqlclient.lib(my_init.obj) : error LNK2019: unresolved external symbol __CrtCheckMemory referenced in function _my_end Do I have to include an aditional library so the symbols are resolved correctly? The release mode works perfect and the application runs fine in that way only... The missing functions should be provided by the Visual Studio debug runtime library. Are all source files in your own code compiled and program linked with one, and only one, of the flags /MDd (dynamic linking) or /MTd (static linking)? Lars Nilsson -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe:http://lists.mysql.com/mysql
RE: Unresolved symbols with mysqlclient in DEBUG mode using VC++ 2010 Express
Miguel.. i do not have VC2010 but as my memory recalls the C runtime library (MSVCRT*.dll) would be the first library on %PATH% .. and all missing functions *should* be located inside the dll (e.g. __CrtSetReportFile ) can you 1) locate MSVCRT*.dll on your %PATH% 2) dumpbin -exports MSVCRT*.dll Saludos Cordiales (desde EEUU) Martin __ Porfavor no altere esta communicacion..Gracias Date: Tue, 19 Jun 2012 10:24:48 -0400 Subject: Re: Unresolved symbols with mysqlclient in DEBUG mode using VC++ 2010 Express From: chamael...@gmail.com To: renit...@gmail.com CC: mysql@lists.mysql.com On Tue, Jun 19, 2012 at 2:48 AM, Miguel Cardenas renit...@gmail.com wrote: Hello friends 1mysqlclient.lib(dbug.obj) : error LNK2019: unresolved external symbol __CrtSetReportFile referenced in function _DbugExit 1mysqlclient.lib(my_init.obj) : error LNK2001: unresolved external symbol __CrtSetReportFile 1mysqlclient.lib(dbug.obj) : error LNK2019: unresolved external symbol __CrtSetReportMode referenced in function _DbugExit 1mysqlclient.lib(my_init.obj) : error LNK2001: unresolved external symbol __CrtSetReportMode 1mysqlclient.lib(my_init.obj) : error LNK2019: unresolved external symbol __CrtDumpMemoryLeaks referenced in function _my_end 1mysqlclient.lib(my_init.obj) : error LNK2019: unresolved external symbol __CrtCheckMemory referenced in function _my_end Do I have to include an aditional library so the symbols are resolved correctly? The release mode works perfect and the application runs fine in that way only... The missing functions should be provided by the Visual Studio debug runtime library. Are all source files in your own code compiled and program linked with one, and only one, of the flags /MDd (dynamic linking) or /MTd (static linking)? Lars Nilsson -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe:http://lists.mysql.com/mysql
Re: Unresolved symbols with mysqlclient in DEBUG mode using VC++ 2010 Express
On Tue, Jun 19, 2012 at 10:47 AM, Martin Gainty mgai...@hotmail.com wrote: Miguel.. i do not have VC2010 but as my memory recalls the C runtime library (MSVCRT*.dll) would be the first library on %PATH% .. and all missing functions *should* be located inside the dll (e.g. __CrtSetReportFile ) can you 1) locate MSVCRT*.dll on your %PATH% 2) dumpbin -exports MSVCRT*.dll The problem is at compile/link-time not run-time dll lookup, so he'll first need to make sure he can link. Once it links, I'd hazard a guess it'll run ok (assuming the program is correct..) Lars Nilsson -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe:http://lists.mysql.com/mysql
Re: Unresolved symbols with mysqlclient in DEBUG mode using VC++ 2010 Express
Hello Lars After hours of testing different project configurations, finally I was able to compile with debug mode... still pending the test of debugging, but just created the DLL (it was a library that I'm developing) without errors... The configurations I used (VC++ 2010 Express) were: RELEASE: - Runtime: /MT (static threaded) - Library: mysqlclient.lib (...\mysql\lib) - Ignore library: LIBCMTD.lib (without this does not link the release) - Debug: NO RELEASE: - Runtime: /MTd (static threaded debug) - Library: mysqlclient.lib (...\mysql\lib\debug) - Ignore library: empty (now allowed LIBCMTD.lib or does not link the debug) - Debug: YES If I try to use /MD or /MDd does not compile, if it works with /MT(d) will leave it that way XD I'm going to test the debug version (one thing is that compiled and another one that works =) and if get stuck again will post it... Thanks for your response P.D. One last question, is it right to use ...\mysql\lib\debug directory for debug version? or it should be set to ...\mysql\lib in both cases and the linker chooses the right one? If compiling in debug mode it works with both ...\mysql\lib and ...\mysql\lib\debug in DEBUG mode... maybe running the debugger will not work with the lib, still have to test, but at least it compiles with no errors... can you comment something about this? On Tue, Jun 19, 2012 at 2:24 PM, Lars Nilsson chamael...@gmail.com wrote: On Tue, Jun 19, 2012 at 2:48 AM, Miguel Cardenas renit...@gmail.com wrote: Hello friends 1mysqlclient.lib(dbug.obj) : error LNK2019: unresolved external symbol __CrtSetReportFile referenced in function _DbugExit 1mysqlclient.lib(my_init.obj) : error LNK2001: unresolved external symbol __CrtSetReportFile 1mysqlclient.lib(dbug.obj) : error LNK2019: unresolved external symbol __CrtSetReportMode referenced in function _DbugExit 1mysqlclient.lib(my_init.obj) : error LNK2001: unresolved external symbol __CrtSetReportMode 1mysqlclient.lib(my_init.obj) : error LNK2019: unresolved external symbol __CrtDumpMemoryLeaks referenced in function _my_end 1mysqlclient.lib(my_init.obj) : error LNK2019: unresolved external symbol __CrtCheckMemory referenced in function _my_end Do I have to include an aditional library so the symbols are resolved correctly? The release mode works perfect and the application runs fine in that way only... The missing functions should be provided by the Visual Studio debug runtime library. Are all source files in your own code compiled and program linked with one, and only one, of the flags /MDd (dynamic linking) or /MTd (static linking)? Lars Nilsson -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe:http://lists.mysql.com/mysql
Re: Unresolved symbols with mysqlclient in DEBUG mode using VC++ 2010 Express
On Tue, Jun 19, 2012 at 11:56 AM, Miguel Cardenas renit...@gmail.com wrote: RELEASE: - Runtime: /MT (static threaded) - Library: mysqlclient.lib (...\mysql\lib) - Ignore library: LIBCMTD.lib (without this does not link the release) - Debug: NO RELEASE: - Runtime: /MTd (static threaded debug) - Library: mysqlclient.lib (...\mysql\lib\debug) - Ignore library: empty (now allowed LIBCMTD.lib or does not link the debug) - Debug: YES If I try to use /MD or /MDd does not compile, if it works with /MT(d) will leave it that way XD I'm going to test the debug version (one thing is that compiled and another one that works =) and if get stuck again will post it... Thanks for your response P.D. One last question, is it right to use ...\mysql\lib\debug directory for debug version? or it should be set to ...\mysql\lib in both cases and the linker chooses the right one? If compiling in debug mode it works with both ...\mysql\lib and ...\mysql\lib\debug in DEBUG mode... maybe running the debugger will not work with the lib, still have to test, but at least it compiles with no errors... can you comment something about this? In general, you'd want to ensure every object file and static library linked into your program is compiled with the same runtime library selected /MT[d] or /MD[d], to ensure a proper working environment. If you were to link with libmysql.lib you'd avoid having to match up these flags for this particular library for your own code. Mixing and matching these flags among things linked into a executable or dll is a recipe for a headache on Windows. Regarding your question about the directory, you'd more than likely want to link with the one in the debug directory, I think, to get useful stack traces into library code when debugging. Lars Nilsson -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe:http://lists.mysql.com/mysql
New releases of Percona Toolkit, Percona Monitoring Plugins
Hi all, I'm happy to announce updates to two of Percona's suites of free (GPL) tools for MySQL. Percona Toolkit versions 2.0.5 and 2.1.2 are released. These are bug-fix releases in the 2.0 and 2.1 series, respectively. These releases fix many dozens of bugs, and we suggest that users upgrade to the latest versions of the tools. Percona Toolkit is a collection of advanced command-line tools to perform a variety of MySQL and system tasks that are too difficult or complex to perform manually. More details: http://goo.gl/cKOVP Percona Monitoring Plugins version 1.0.1 is released. This is a routine bug-fix release that addresses several minor issues. The Percona Monitoring Plugins are high-quality components to add enterprise-grade MySQL monitoring and graphing capabilities to your existing in-house, on-premises monitoring solutions. More details: http://goo.gl/HGbnt Regards, Baron -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe:http://lists.mysql.com/mysql
optimize DB - bad experience
Hi Guys, Just curious if any of you had a bad experience running optimize table procedure. ERRORS, corrupted databases or tables caused by this. We have MySQL 5.1.46 server. I feel to run optimize of the full DB is quite safe Example: shell mysqlcheck -o --skip-write-binlog database What's your stories on this one? Many thanks, Igor -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe:http://lists.mysql.com/mysql
RE: optimize DB - bad experience
OPTIMIZE TABLE is almost never needed. I certainly don't blast away at all tables. -Original Message- From: Igor Shevtsov [mailto:nixofort...@gmail.com] Sent: Tuesday, June 19, 2012 2:04 PM To: mysql@lists.mysql.com Subject: optimize DB - bad experience Hi Guys, Just curious if any of you had a bad experience running optimize table procedure. ERRORS, corrupted databases or tables caused by this. We have MySQL 5.1.46 server. I feel to run optimize of the full DB is quite safe Example: shell mysqlcheck -o --skip-write-binlog database What's your stories on this one? Many thanks, Igor -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe:http://lists.mysql.com/mysql -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe:http://lists.mysql.com/mysql
