FAQ
Below is the rest of it...

5) The simple main function
6) gdb run with backtrace

5) Code:
#include <iostream>
#include <string>
#include <mysql++.h>

using namespace std;
using namespace mysqlpp;

int main (int argc, char * const argv[])
{
string database_name = "tac_db_rev_4";
string ip_address = "X.X.X.X";
string username = "admin";
string password = "admin";
string client_id = "graham";
string client_pw = "reitz";
string error_msg;

cout << "Attempting to connect to the database...";

Connection m_connection(database_name.c_str(),
ip_address.c_str(),
username.c_str(),
password.c_str(),
3306,
false,
15);

Result client_id_result;

try
{

cout << "connected to the database\n";

Query client_id_query = m_connection.query();

client_id_query <<
"select client_id from clients where client_user_name ="
<< quote_only << client_id << " and client_password ="
<< quote_only << client_pw;

cout << "Query created: " << client_id_query.preview() << endl;

client_id_result = client_id_query.store();

if (client_id_result)
{
cout << "Result received = " << client_id_result.rows()
<< endl;
Row client_id_row;
Row::size_type i = 0;
client_id_row = client_id_result.at(i);
}

Row client_id_row;
// The "=" versus "==" syntax is more mysqlpp bs
if (client_id_row = client_id_result.at(0))
{
cout << client_id_row.at(0) << endl;
return client_id_row.at(0);
}
}
catch (exception &e)
{
cout << "exception occurred...";
cout << e.what() << endl;
}
catch (...)
{
error_msg = "Unknown exception";
cout << error_msg << endl;
}

m_connection.close();

return 0;
}

6) gdb run with backtrace

(gdb) run
Starting program: /Users/grahamreitz/Development/Projects/tac/build/
Debug/tac
Reading symbols for shared libraries ++++++... done
Attempting to connect to the database...connected to the database
Query created: select client_id from clients where client_user_name
='graham' and client_password ='reitz'
Result received = 1
/Developer/SDKs/MacOSX10.5.sdk/usr/include/c++/4.0.0/bits/
stl_algobase.h:382:
error: function requires a valid iterator range [__first, __last).

Objects involved in the operation:
iterator "__first" @ 0x0xbfffee50 {
type = N10__gnu_norm19_Bit_const_iteratorE;
}
iterator "__last" @ 0x0xbfffee58 {
type = N10__gnu_norm19_Bit_const_iteratorE;
}

Program received signal SIGABRT, Aborted.
0x9264e47a in __kill ()
(gdb) backtrace
#0 0x9264e47a in __kill ()
#1 0x9264e46d in kill$UNIX2003 ()
#2 0x926c5782 in raise ()
#3 0x926d4d3f in abort ()
#4 0x92b476f9 in __gnu_debug::_Error_formatter::_M_error ()
#5 0x00005bdb in std::copy<__gnu_norm::_Bit_const_iterator,
__gnu_norm::_Bit_iterator> (__first={<__gnu_norm::_Bit_iterator_base>
= {<> = {<No data fields>}, _M_p = 0x700bc4, _M_offset = 3221222728},
<No data fields>}, __last={<__gnu_norm::_Bit_iterator_base> = {<> =
{<No data fields>}, _M_p = 0xbffff601, _M_offset = 2413828210}, <No
data fields>}, __result={<__gnu_norm::_Bit_iterator_base> = {<> = {<No
data fields>}, _M_p = 0x1000000, _M_offset = 0}, <No data fields>}) at
stl_algobase.h:382
#6 0x00005cd6 in __gnu_norm::vector<bool, std::allocator<bool>
::operator= (this=0xbffff4c8, __x=@0xbffff5f0) at stl_bvector.h:709
#7 0x00005d3a in __gnu_debug_def::vector<bool, std::allocator<bool>
::operator= (this=0xbffff4c8, __x=@0xbffff5f0) at debug/vector:100
#8 0x00006eb4 in mysqlpp::Row::operator= (this=0xbffff4a0) at row.h:54
#9 0x00001ef9 in main (argc=1, argv=0xbffff6f0) at /Users/grahamreitz/
Development/Projects/tac/main.cpp:51

Search Discussions

  • Graham Reitz at Dec 5, 2007 at 4:46 am
    The madness can finally end. Ugh...I figured it out.

    Can you guys explain why? (I'll look too for an answer)

    When you create a C++ Command Line Tool project in Xcode 3.0 it adds
    the following preprocessor defines:

    _GLIBCXX_DEBUG=1 _GLIBCXX_DEBUG_PEDANTIC=1

    When these are there it crashes in debug mode. When they are not
    there everything works great. Even if I set the to =0 it still crashes.

    Any ideas?

    Thanks,
    graham
  • Graham Reitz at Dec 5, 2007 at 5:00 am
    Specifically it's this one:

    _GLIBCXX_DEBUG=1

    On Dec 4, 2007, at 10:46 PM, Graham Reitz wrote:

    The madness can finally end. Ugh...I figured it out.

    Can you guys explain why? (I'll look too for an answer)

    When you create a C++ Command Line Tool project in Xcode 3.0 it adds
    the following preprocessor defines:

    _GLIBCXX_DEBUG=1 _GLIBCXX_DEBUG_PEDANTIC=1

    When these are there it crashes in debug mode. When they are not
    there everything works great. Even if I set the to =0 it still
    crashes.

    Any ideas?

    Thanks,
    graham

    --
    MySQL++ Mailing List
    For list archives: http://lists.mysql.com/plusplus
    To unsubscribe: http://lists.mysql.com/plusplus?unsub=grahamreitz@mac.com
  • Warren Young at Dec 5, 2007 at 4:17 pm

    Graham Reitz wrote:

    When you create a C++ Command Line Tool project in Xcode 3.0 it adds the
    following preprocessor defines:

    _GLIBCXX_DEBUG=1 _GLIBCXX_DEBUG_PEDANTIC=1

    When these are there it crashes in debug mode.
    The mighty Google says these flags turn on internal debugging within the
    standard libraries, or at least within STL.

    It may be that you have to use these flags for all modules within the
    project, which wouldn't happen if you're building MySQL++ using the
    standard configure && make && make install pattern.

    If you did indeed build MySQL++ this way, try this:

    $ cd /mysqlpp/directory
    $ make clean
    $ ./configure CXXFLAGS="_GLIBCXX_DEBUG=1 _GLIBCXX_DEBUG_PEDANTIC=1"
    $ make && sudo make install

    This would be the "debug version" you sought after earlier, though there
    is no way to distinguish it from a release version from the outside.
    Even if I set the to =0 it still crashes.
    Clearly some code is using #if defined(X) or #ifdef X instead of #if X
    to decide whether this flag is "on".
  • Jonathan Wakely at Dec 5, 2007 at 9:24 pm

    On 05/12/2007, Warren Young wrote:
    It may be that you have to use these flags for all modules within the
    project, which wouldn't happen if you're building MySQL++ using the
    standard configure && make && make install pattern.
    If the code definitely doesn't violate any STL preconditions then that
    could be the problem. you can't mix and match debug mode objects with
    non-debug mode objects if you pass types such as std::string or
    std::vector between objects.
    Even if I set the to =0 it still crashes.
    Clearly some code is using #if defined(X) or #ifdef X instead of #if X
    to decide whether this flag is "on".
    That's intentional.

    Jon
  • Graham Reitz at Dec 5, 2007 at 10:43 pm
    Thanks Jon,

    Ahh...so the problem is with mixing debug and release builds with
    release libraries? That makes sense.

    I thought, since mysql++ doesn't come with a debug build, that it
    shouldn't matter. Whose going to write an application and not use
    debug mode for at least a little while?

    Is the intention when using the mysql++ dylibs that we will never need
    to build in debug mode? I am a little confused here. I know with the
    boost libs the default build creates both the debug and release libs.
    Why doesn't mysql++? Is this some mysqlclient limitation?

    thanks again,
    graham
    On Dec 5, 2007, at 3:24 PM, Jonathan Wakely wrote:
    On 05/12/2007, Warren Young wrote:
    It may be that you have to use these flags for all modules within the
    project, which wouldn't happen if you're building MySQL++ using the
    standard configure && make && make install pattern.
    If the code definitely doesn't violate any STL preconditions then that
    could be the problem. you can't mix and match debug mode objects with
    non-debug mode objects if you pass types such as std::string or
    std::vector between objects.
    Even if I set the to =0 it still crashes.
    Clearly some code is using #if defined(X) or #ifdef X instead of
    #if X
    to decide whether this flag is "on".
    That's intentional.

    Jon

    --
    MySQL++ Mailing List
    For list archives: http://lists.mysql.com/plusplus
    To unsubscribe: http://lists.mysql.com/plusplus?unsub=grahamreitz@mac.com
  • Jonathan Wakely at Dec 5, 2007 at 11:02 pm

    On 05/12/2007, Graham Reitz wrote:
    I thought, since mysql++ doesn't come with a debug build, that it
    shouldn't matter. Whose going to write an application and not use
    debug mode for at least a little while?

    Is the intention when using the mysql++ dylibs that we will never need
    to build in debug mode? I am a little confused here. I know with the
    boost libs the default build creates both the debug and release libs.
    What Boost builds are libraries with debug symbols, for use with a
    debugger. You usually request this from the compiler with -g. This is
    very different from compiling with a checked STL, such as GCC's Debug
    Mode. Very different indeed.
    AFAIK Boost does not build libs with GCC's Debug Mode turned on, I
    used to test Boost and GCC using the debug mode and had to enable it
    specifically.
    I didn't realise Xcode turns it on for "debug builds" - usually that
    would just mean -g to me (some compilers will also do no optimisations
    for debug builds, but GCC supports -O and -g at the same time.)

    Jon
  • Warren Young at Dec 6, 2007 at 12:56 am

    Graham Reitz wrote:

    Why doesn't mysql++ [have a special debug build mode]?
    There's no real history of such things on *ix systems, so where it is
    done, it's done in some way particular to that system. And, if you use
    the Unixy command line build systems on OS X, the current behavior is
    fine. This is no doubt why you're the first to bring this to my attention.

    Compare Visual Studio. Almost everyone uses the IDE, not the command
    line tools, and the IDE sets up both debug and release builds for any
    new project. It's both standard and the default, so everyone does it.

    On OS X, what we have here are two different use cases, so they should
    be handled separately: autoconf with no special debug modes for command
    line geeks like me, and Xcode project files set up to build both debug
    and release versions for folk like you. Bakefile can generate Xcode
    project files, so it's just a matter of using them.

    I nominate you to do it. :) Seriously. I use OS X every day, but
    beyond some "Hello, world" toy programs, I've never used Xcode the IDE.
    You're in the best position to scratch this itch.

    Xcode project support apparently goes back to 0.1.9 in Bakefile, but
    there are reportedly big improvements in svn, so I'd recommend you use
    that, at least to start. Later you can roll back to 0.1.9 to see if it
    still works adequately. I'm already of half a mind to make MySQL++ v3.0
    wait on Bakefile 0.2.3 to get VC2003 support.

    The v3 effort is getting close to winding up, but you've probably got a
    few weeks at least to get something to me.
  • Graham Reitz at Dec 6, 2007 at 4:08 am
    Ok cool. Thanks guys. I will get that done Warren.

    It will be good experience for me. I start vacation on the 14th and
    will get that rolling at that point. It would be really nice to have
    Xcode project files for mysql++. (People like me won't be able to do
    this again.)

    Thanks for that link Jon. This says it all:

    "To use the libstdc++ debug mode, compile your application with the
    compiler flag -D_GLIBCXX_DEBUG. Note that this flag changes the sizes
    and behavior of standard class templates such as std::vector, and
    therefore you can only link code compiled with debug mode and code
    compiled without debug mode if no instantiation of a container is
    passed between the two translation units."

    What I wasn't aware of is that you can link debug (-g) and release
    code but not when D_GLIBCXX_DEBUG has been defined (if containers are
    passed between cpps). It seems like using D_GLIBCXX_DEBUG is a really
    good idea when debugging since it will catch improper usage of the
    stdlibc++.

    graham

    On Dec 5, 2007, at 6:56 PM, Warren Young wrote:

    Graham Reitz wrote:
    Why doesn't mysql++ [have a special debug build mode]?
    There's no real history of such things on *ix systems, so where it
    is done, it's done in some way particular to that system. And, if
    you use the Unixy command line build systems on OS X, the current
    behavior is fine. This is no doubt why you're the first to bring
    this to my attention.

    Compare Visual Studio. Almost everyone uses the IDE, not the
    command line tools, and the IDE sets up both debug and release
    builds for any new project. It's both standard and the default, so
    everyone does it.

    On OS X, what we have here are two different use cases, so they
    should be handled separately: autoconf with no special debug modes
    for command line geeks like me, and Xcode project files set up to
    build both debug and release versions for folk like you. Bakefile
    can generate Xcode project files, so it's just a matter of using them.

    I nominate you to do it. :) Seriously. I use OS X every day, but
    beyond some "Hello, world" toy programs, I've never used Xcode the
    IDE. You're in the best position to scratch this itch.

    Xcode project support apparently goes back to 0.1.9 in Bakefile, but
    there are reportedly big improvements in svn, so I'd recommend you
    use that, at least to start. Later you can roll back to 0.1.9 to
    see if it still works adequately. I'm already of half a mind to
    make MySQL++ v3.0 wait on Bakefile 0.2.3 to get VC2003 support.

    The v3 effort is getting close to winding up, but you've probably
    got a few weeks at least to get something to me.

    --
    MySQL++ Mailing List
    For list archives: http://lists.mysql.com/plusplus
    To unsubscribe: http://lists.mysql.com/plusplus?unsub=grahamreitz@mac.com
  • Graham Reitz at Dec 6, 2007 at 5:20 am
    Huh weird.

    I built mysql++ the following way:

    make clean
    ./configure CXXFLAGS="-g -D_GLIBCXX_DEBUG=1 -
    D_GLIBCXX_DEBUG_PEDANTIC=1" --with-mysql=/sw
    make

    The resulting dylib is a little less than 50% larger than the original.

    I then renamed the dylib (added a _d) and copied the dylib over to
    the /usr/local/lib directory and updated the Xcode project to use the
    new mysql++ dylib.

    I received the same assertion as before when running the debug build.

    I was a little suspicious that the original dylib was getting loaded
    anyways...

    I then copied over the new (with _DEBUG) libmysqlpp.dylib to /usr/
    local/lib and it worked fine.

    Is there something that caused the original libmysqlpp.dylib to get
    loaded instead of the renamed libmysqlpp_d.dylib, even though I told
    it not to in Xcode?

    thanks,
    graham
    On Dec 5, 2007, at 10:08 PM, Graham Reitz wrote:

    Ok cool. Thanks guys. I will get that done Warren.

    It will be good experience for me. I start vacation on the 14th and
    will get that rolling at that point. It would be really nice to
    have Xcode project files for mysql++. (People like me won't be able
    to do this again.)

    Thanks for that link Jon. This says it all:

    "To use the libstdc++ debug mode, compile your application with the
    compiler flag -D_GLIBCXX_DEBUG. Note that this flag changes the
    sizes and behavior of standard class templates such as std::vector,
    and therefore you can only link code compiled with debug mode and
    code compiled without debug mode if no instantiation of a container
    is passed between the two translation units."

    What I wasn't aware of is that you can link debug (-g) and release
    code but not when D_GLIBCXX_DEBUG has been defined (if containers
    are passed between cpps). It seems like using D_GLIBCXX_DEBUG is a
    really good idea when debugging since it will catch improper usage
    of the stdlibc++.

    graham

    On Dec 5, 2007, at 6:56 PM, Warren Young wrote:

    Graham Reitz wrote:
    Why doesn't mysql++ [have a special debug build mode]?
    There's no real history of such things on *ix systems, so where it
    is done, it's done in some way particular to that system. And, if
    you use the Unixy command line build systems on OS X, the current
    behavior is fine. This is no doubt why you're the first to bring
    this to my attention.

    Compare Visual Studio. Almost everyone uses the IDE, not the
    command line tools, and the IDE sets up both debug and release
    builds for any new project. It's both standard and the default, so
    everyone does it.

    On OS X, what we have here are two different use cases, so they
    should be handled separately: autoconf with no special debug modes
    for command line geeks like me, and Xcode project files set up to
    build both debug and release versions for folk like you. Bakefile
    can generate Xcode project files, so it's just a matter of using
    them.

    I nominate you to do it. :) Seriously. I use OS X every day, but
    beyond some "Hello, world" toy programs, I've never used Xcode the
    IDE. You're in the best position to scratch this itch.

    Xcode project support apparently goes back to 0.1.9 in Bakefile,
    but there are reportedly big improvements in svn, so I'd recommend
    you use that, at least to start. Later you can roll back to 0.1.9
    to see if it still works adequately. I'm already of half a mind to
    make MySQL++ v3.0 wait on Bakefile 0.2.3 to get VC2003 support.

    The v3 effort is getting close to winding up, but you've probably
    got a few weeks at least to get something to me.

    --
    MySQL++ Mailing List
    For list archives: http://lists.mysql.com/plusplus
    To unsubscribe: http://lists.mysql.com/plusplus?unsub=grahamreitz@mac.com
  • Graham Reitz at Dec 6, 2007 at 11:17 pm
    I figured it out. I had to change the location where it looks for the
    dylib.

    thanks,
    g
    On Dec 5, 2007, at 11:19 PM, Graham Reitz wrote:

    Huh weird.

    I built mysql++ the following way:

    make clean
    ./configure CXXFLAGS="-g -D_GLIBCXX_DEBUG=1 -
    D_GLIBCXX_DEBUG_PEDANTIC=1" --with-mysql=/sw
    make

    The resulting dylib is a little less than 50% larger than the
    original.

    I then renamed the dylib (added a _d) and copied the dylib over to
    the /usr/local/lib directory and updated the Xcode project to use
    the new mysql++ dylib.

    I received the same assertion as before when running the debug build.

    I was a little suspicious that the original dylib was getting loaded
    anyways...

    I then copied over the new (with _DEBUG) libmysqlpp.dylib to /usr/
    local/lib and it worked fine.

    Is there something that caused the original libmysqlpp.dylib to get
    loaded instead of the renamed libmysqlpp_d.dylib, even though I told
    it not to in Xcode?

    thanks,
    graham
    On Dec 5, 2007, at 10:08 PM, Graham Reitz wrote:

    Ok cool. Thanks guys. I will get that done Warren.

    It will be good experience for me. I start vacation on the 14th
    and will get that rolling at that point. It would be really nice
    to have Xcode project files for mysql++. (People like me won't be
    able to do this again.)

    Thanks for that link Jon. This says it all:

    "To use the libstdc++ debug mode, compile your application with the
    compiler flag -D_GLIBCXX_DEBUG. Note that this flag changes the
    sizes and behavior of standard class templates such as std::vector,
    and therefore you can only link code compiled with debug mode and
    code compiled without debug mode if no instantiation of a container
    is passed between the two translation units."

    What I wasn't aware of is that you can link debug (-g) and release
    code but not when D_GLIBCXX_DEBUG has been defined (if containers
    are passed between cpps). It seems like using D_GLIBCXX_DEBUG is a
    really good idea when debugging since it will catch improper usage
    of the stdlibc++.

    graham

    On Dec 5, 2007, at 6:56 PM, Warren Young wrote:

    Graham Reitz wrote:
    Why doesn't mysql++ [have a special debug build mode]?
    There's no real history of such things on *ix systems, so where it
    is done, it's done in some way particular to that system. And, if
    you use the Unixy command line build systems on OS X, the current
    behavior is fine. This is no doubt why you're the first to bring
    this to my attention.

    Compare Visual Studio. Almost everyone uses the IDE, not the
    command line tools, and the IDE sets up both debug and release
    builds for any new project. It's both standard and the default,
    so everyone does it.

    On OS X, what we have here are two different use cases, so they
    should be handled separately: autoconf with no special debug modes
    for command line geeks like me, and Xcode project files set up to
    build both debug and release versions for folk like you. Bakefile
    can generate Xcode project files, so it's just a matter of using
    them.

    I nominate you to do it. :) Seriously. I use OS X every day, but
    beyond some "Hello, world" toy programs, I've never used Xcode the
    IDE. You're in the best position to scratch this itch.

    Xcode project support apparently goes back to 0.1.9 in Bakefile,
    but there are reportedly big improvements in svn, so I'd recommend
    you use that, at least to start. Later you can roll back to 0.1.9
    to see if it still works adequately. I'm already of half a mind
    to make MySQL++ v3.0 wait on Bakefile 0.2.3 to get VC2003 support.

    The v3 effort is getting close to winding up, but you've probably
    got a few weeks at least to get something to me.

    --
    MySQL++ Mailing List
    For list archives: http://lists.mysql.com/plusplus
    To unsubscribe: http://lists.mysql.com/plusplus?unsub=grahamreitz@mac.com

    --
    MySQL++ Mailing List
    For list archives: http://lists.mysql.com/plusplus
    To unsubscribe: http://lists.mysql.com/plusplus?unsub=grahamreitz@mac.com
  • Graham Reitz at Dec 6, 2007 at 11:23 pm
    Ok maybe not. Was this set in the mysqlpp dylib build?
    LD_DYLIB_INSTALL_NAME (-install_name)

    "Sets an internal "install path" (LC_ID_DYLIB) in a dynamic library.
    Any clients linked against the library will record that path as the
    way dyld should locate this library. If this option is not specified,
    then the -o path will be used. This setting is ignored when building
    any product other than a dynamic library. [LD_DYLIB_INSTALL_NAME, -
    install_name]"

    This sounds like, no matter what I do, this will make anything that
    links against the mysqlpp dylib will use the path specified. In this
    case /usr/local/lib?

    It seems like this might be happening. Not matter what I put in my
    project the final executable always looks for the mysqlpp dylib in /
    usr/local/lib. I have been using otool -L to see if it is changing
    and it's not.

    Any ideas?

    thanks,
    graham
    On Dec 6, 2007, at 5:17 PM, Graham Reitz wrote:

    I figured it out. I had to change the location where it looks for
    the dylib.

    thanks,
    g
    On Dec 5, 2007, at 11:19 PM, Graham Reitz wrote:

    Huh weird.

    I built mysql++ the following way:

    make clean
    ./configure CXXFLAGS="-g -D_GLIBCXX_DEBUG=1 -
    D_GLIBCXX_DEBUG_PEDANTIC=1" --with-mysql=/sw
    make

    The resulting dylib is a little less than 50% larger than the
    original.

    I then renamed the dylib (added a _d) and copied the dylib over to
    the /usr/local/lib directory and updated the Xcode project to use
    the new mysql++ dylib.

    I received the same assertion as before when running the debug build.

    I was a little suspicious that the original dylib was getting
    loaded anyways...

    I then copied over the new (with _DEBUG) libmysqlpp.dylib to /usr/
    local/lib and it worked fine.

    Is there something that caused the original libmysqlpp.dylib to get
    loaded instead of the renamed libmysqlpp_d.dylib, even though I
    told it not to in Xcode?

    thanks,
    graham
    On Dec 5, 2007, at 10:08 PM, Graham Reitz wrote:

    Ok cool. Thanks guys. I will get that done Warren.

    It will be good experience for me. I start vacation on the 14th
    and will get that rolling at that point. It would be really nice
    to have Xcode project files for mysql++. (People like me won't be
    able to do this again.)

    Thanks for that link Jon. This says it all:

    "To use the libstdc++ debug mode, compile your application with
    the compiler flag -D_GLIBCXX_DEBUG. Note that this flag changes
    the sizes and behavior of standard class templates such as
    std::vector, and therefore you can only link code compiled with
    debug mode and code compiled without debug mode if no
    instantiation of a container is passed between the two translation
    units."

    What I wasn't aware of is that you can link debug (-g) and release
    code but not when D_GLIBCXX_DEBUG has been defined (if containers
    are passed between cpps). It seems like using D_GLIBCXX_DEBUG is a
    really good idea when debugging since it will catch improper usage
    of the stdlibc++.

    graham

    On Dec 5, 2007, at 6:56 PM, Warren Young wrote:

    Graham Reitz wrote:
    Why doesn't mysql++ [have a special debug build mode]?
    There's no real history of such things on *ix systems, so where
    it is done, it's done in some way particular to that system.
    And, if you use the Unixy command line build systems on OS X, the
    current behavior is fine. This is no doubt why you're the first
    to bring this to my attention.

    Compare Visual Studio. Almost everyone uses the IDE, not the
    command line tools, and the IDE sets up both debug and release
    builds for any new project. It's both standard and the default,
    so everyone does it.

    On OS X, what we have here are two different use cases, so they
    should be handled separately: autoconf with no special debug
    modes for command line geeks like me, and Xcode project files set
    up to build both debug and release versions for folk like you.
    Bakefile can generate Xcode project files, so it's just a matter
    of using them.

    I nominate you to do it. :) Seriously. I use OS X every day,
    but beyond some "Hello, world" toy programs, I've never used
    Xcode the IDE. You're in the best position to scratch this itch.

    Xcode project support apparently goes back to 0.1.9 in Bakefile,
    but there are reportedly big improvements in svn, so I'd
    recommend you use that, at least to start. Later you can roll
    back to 0.1.9 to see if it still works adequately. I'm already
    of half a mind to make MySQL++ v3.0 wait on Bakefile 0.2.3 to get
    VC2003 support.

    The v3 effort is getting close to winding up, but you've probably
    got a few weeks at least to get something to me.

    --
    MySQL++ Mailing List
    For list archives: http://lists.mysql.com/plusplus
    To unsubscribe: http://lists.mysql.com/plusplus?unsub=grahamreitz@mac.com

    --
    MySQL++ Mailing List
    For list archives: http://lists.mysql.com/plusplus
    To unsubscribe: http://lists.mysql.com/plusplus?unsub=grahamreitz@mac.com

    --
    MySQL++ Mailing List
    For list archives: http://lists.mysql.com/plusplus
    To unsubscribe: http://lists.mysql.com/plusplus?unsub=grahamreitz@mac.com
  • Graham Reitz at Dec 7, 2007 at 8:21 pm
    Ok i have an answer for this.

    It's all in the man pages for :

    dyld(1) dyld(3)
    ld(1), otool(1) and install_name_tool(1)

    thanks,
    graham
    On Dec 6, 2007, at 5:23 PM, Graham Reitz wrote:

    Ok maybe not. Was this set in the mysqlpp dylib build?
    LD_DYLIB_INSTALL_NAME (-install_name)

    "Sets an internal "install path" (LC_ID_DYLIB) in a dynamic library.
    Any clients linked against the library will record that path as the
    way dyld should locate this library. If this option is not
    specified, then the -o path will be used. This setting is ignored
    when building any product other than a dynamic library.
    [LD_DYLIB_INSTALL_NAME, -install_name]"

    This sounds like, no matter what I do, this will make anything that
    links against the mysqlpp dylib will use the path specified. In
    this case /usr/local/lib?

    It seems like this might be happening. Not matter what I put in my
    project the final executable always looks for the mysqlpp dylib in /
    usr/local/lib. I have been using otool -L to see if it is changing
    and it's not.

    Any ideas?

    thanks,
    graham
    On Dec 6, 2007, at 5:17 PM, Graham Reitz wrote:

    I figured it out. I had to change the location where it looks for
    the dylib.

    thanks,
    g
    On Dec 5, 2007, at 11:19 PM, Graham Reitz wrote:

    Huh weird.

    I built mysql++ the following way:

    make clean
    ./configure CXXFLAGS="-g -D_GLIBCXX_DEBUG=1 -
    D_GLIBCXX_DEBUG_PEDANTIC=1" --with-mysql=/sw
    make

    The resulting dylib is a little less than 50% larger than the
    original.

    I then renamed the dylib (added a _d) and copied the dylib over to
    the /usr/local/lib directory and updated the Xcode project to use
    the new mysql++ dylib.

    I received the same assertion as before when running the debug
    build.

    I was a little suspicious that the original dylib was getting
    loaded anyways...

    I then copied over the new (with _DEBUG) libmysqlpp.dylib to /usr/
    local/lib and it worked fine.

    Is there something that caused the original libmysqlpp.dylib to
    get loaded instead of the renamed libmysqlpp_d.dylib, even though
    I told it not to in Xcode?

    thanks,
    graham
    On Dec 5, 2007, at 10:08 PM, Graham Reitz wrote:

    Ok cool. Thanks guys. I will get that done Warren.

    It will be good experience for me. I start vacation on the 14th
    and will get that rolling at that point. It would be really nice
    to have Xcode project files for mysql++. (People like me won't
    be able to do this again.)

    Thanks for that link Jon. This says it all:

    "To use the libstdc++ debug mode, compile your application with
    the compiler flag -D_GLIBCXX_DEBUG. Note that this flag changes
    the sizes and behavior of standard class templates such as
    std::vector, and therefore you can only link code compiled with
    debug mode and code compiled without debug mode if no
    instantiation of a container is passed between the two
    translation units."

    What I wasn't aware of is that you can link debug (-g) and
    release code but not when D_GLIBCXX_DEBUG has been defined (if
    containers are passed between cpps). It seems like using
    D_GLIBCXX_DEBUG is a really good idea when debugging since it
    will catch improper usage of the stdlibc++.

    graham

    On Dec 5, 2007, at 6:56 PM, Warren Young wrote:

    Graham Reitz wrote:
    Why doesn't mysql++ [have a special debug build mode]?
    There's no real history of such things on *ix systems, so where
    it is done, it's done in some way particular to that system.
    And, if you use the Unixy command line build systems on OS X,
    the current behavior is fine. This is no doubt why you're the
    first to bring this to my attention.

    Compare Visual Studio. Almost everyone uses the IDE, not the
    command line tools, and the IDE sets up both debug and release
    builds for any new project. It's both standard and the default,
    so everyone does it.

    On OS X, what we have here are two different use cases, so they
    should be handled separately: autoconf with no special debug
    modes for command line geeks like me, and Xcode project files
    set up to build both debug and release versions for folk like
    you. Bakefile can generate Xcode project files, so it's just a
    matter of using them.

    I nominate you to do it. :) Seriously. I use OS X every day,
    but beyond some "Hello, world" toy programs, I've never used
    Xcode the IDE. You're in the best position to scratch this itch.

    Xcode project support apparently goes back to 0.1.9 in Bakefile,
    but there are reportedly big improvements in svn, so I'd
    recommend you use that, at least to start. Later you can roll
    back to 0.1.9 to see if it still works adequately. I'm already
    of half a mind to make MySQL++ v3.0 wait on Bakefile 0.2.3 to
    get VC2003 support.

    The v3 effort is getting close to winding up, but you've
    probably got a few weeks at least to get something to me.

    --
    MySQL++ Mailing List
    For list archives: http://lists.mysql.com/plusplus
    To unsubscribe: http://lists.mysql.com/plusplus?unsub=grahamreitz@mac.com

    --
    MySQL++ Mailing List
    For list archives: http://lists.mysql.com/plusplus
    To unsubscribe: http://lists.mysql.com/plusplus?unsub=grahamreitz@mac.com

    --
    MySQL++ Mailing List
    For list archives: http://lists.mysql.com/plusplus
    To unsubscribe: http://lists.mysql.com/plusplus?unsub=grahamreitz@mac.com
  • Jonathan Wakely at Dec 6, 2007 at 11:44 pm

    On 06/12/2007, Graham Reitz wrote:
    What I wasn't aware of is that you can link debug (-g) and release
    code but not when D_GLIBCXX_DEBUG has been defined (if containers are
    passed between cpps). It seems like using D_GLIBCXX_DEBUG is a really
    good idea when debugging since it will catch improper usage of the
    stdlibc++.
    Personally I think it's a good idea to *test* your software with Debug
    Mode (or some other checked STL) as you would test with a memory
    checker such as valgrind or purify, or a profiler, but it's not
    something I would use for all non-release builds.

    I still find it very surprising that Xcode defines those macros for
    you, I would expect it to be something you have to ask for quite
    explicitly. Otherwise it is very difficult to debug any C++ program
    that links to shared libraries, unless you recompile all those libs
    (which is not a reasonable requirement.)

    Jon
  • Warren Young at Jan 10, 2008 at 4:08 am

    Graham Reitz wrote:
    Ok cool. Thanks guys. I will get that done Warren.

    It will be good experience for me. I start vacation on the 14th and
    will get that rolling at that point.
    Lacking a patch from you, I've gone ahead and done as much of this as I
    know how to do. It now needs testing and correction from someone who
    actually uses Xcode regularly.

    Areas of concern:

    - Does it, in fact, work?

    - Is there a way to get Xcode to build ssqls.h and querydef.h, or is it
    going to be like with all the other non-autoconf platforms, where the
    library user either takes what they're given, or has to run the Perl
    scripts by hand?

    - I'm guessing that since the point of an Xcode build option is that you
    don't have to visit the command line, that the MySQL distro of choice
    will be the official mysql.com binaries, as opposed to source installs
    or the Fink package I'm familiar with. I've pulled a directory name out
    of my fuzzy memory which is probably wrong.

    - I couldn't get the -D_GLIBCXX_DEBUG=1 -D_GLIBCXX_DEBUG_PEDANTIC=1
    stuff to appear in the generated project, but maybe it's automatic in
    debug mode targets?
  • Jonathan Wakely at Dec 5, 2007 at 9:22 pm

    On 04/12/2007, Graham Reitz wrote:
    Below is the rest of it...

    5) The simple main function
    6) gdb run with backtrace

    5) Code:
    #include <iostream>
    #include <string>
    #include <mysql++.h>

    using namespace std;
    using namespace mysqlpp;

    int main (int argc, char * const argv[])
    {
    string database_name = "tac_db_rev_4";
    string ip_address = "X.X.X.X";
    string username = "admin";
    string password = "admin";
    string client_id = "graham";
    string client_pw = "reitz";
    string error_msg;

    cout << "Attempting to connect to the database...";

    Connection m_connection(database_name.c_str(),
    ip_address.c_str(),
    username.c_str(),
    password.c_str(),
    3306,
    false,
    15);

    Result client_id_result;

    try
    {

    cout << "connected to the database\n";

    Query client_id_query = m_connection.query();

    client_id_query <<
    "select client_id from clients where client_user_name ="
    << quote_only << client_id << " and client_password ="
    << quote_only << client_pw;

    cout << "Query created: " << client_id_query.preview() << endl;

    client_id_result = client_id_query.store();

    if (client_id_result)
    {
    cout << "Result received = " << client_id_result.rows()
    << endl;
    Row client_id_row;
    Row::size_type i = 0;
    client_id_row = client_id_result.at(i);
    }

    Row client_id_row;
    // The "=" versus "==" syntax is more mysqlpp bs
    if (client_id_row = client_id_result.at(0))
    {
    cout << client_id_row.at(0) << endl;
    return client_id_row.at(0);
    }
    }
    catch (exception &e)
    {
    cout << "exception occurred...";
    cout << e.what() << endl;
    }
    catch (...)
    {
    error_msg = "Unknown exception";
    cout << error_msg << endl;
    }

    m_connection.close();

    return 0;
    }

    6) gdb run with backtrace

    (gdb) run
    Starting program: /Users/grahamreitz/Development/Projects/tac/build/
    Debug/tac
    Reading symbols for shared libraries ++++++... done
    Attempting to connect to the database...connected to the database
    Query created: select client_id from clients where client_user_name
    ='graham' and client_password ='reitz'
    Result received = 1
    /Developer/SDKs/MacOSX10.5.sdk/usr/include/c++/4.0.0/bits/
    This isn't a crash. This is a failed assertion in debug mode. It
    even tells you why:
    stl_algobase.h:382:
    error: function requires a valid iterator range [__first, __last).

    Objects involved in the operation:
    iterator "__first" @ 0x0xbfffee50 {
    type = N10__gnu_norm19_Bit_const_iteratorE;
    }
    iterator "__last" @ 0x0xbfffee58 {
    type = N10__gnu_norm19_Bit_const_iteratorE;
    }

    Program received signal SIGABRT, Aborted.
    0x9264e47a in __kill ()
    (gdb) backtrace
    #0 0x9264e47a in __kill ()
    #1 0x9264e46d in kill$UNIX2003 ()
    #2 0x926c5782 in raise ()
    #3 0x926d4d3f in abort ()
    #4 0x92b476f9 in __gnu_debug::_Error_formatter::_M_error ()
    #5 0x00005bdb in std::copy<__gnu_norm::_Bit_const_iterator,
    __gnu_norm::_Bit_iterator> (__first={<__gnu_norm::_Bit_iterator_base>
    = {<> = {<No data fields>}, _M_p = 0x700bc4, _M_offset = 3221222728},
    <No data fields>}, __last={<__gnu_norm::_Bit_iterator_base> = {<> =
    {<No data fields>}, _M_p = 0xbffff601, _M_offset = 2413828210}, <No
    data fields>}, __result={<__gnu_norm::_Bit_iterator_base> = {<> = {<No
    data fields>}, _M_p = 0x1000000, _M_offset = 0}, <No data fields>}) at
    stl_algobase.h:382
    #6 0x00005cd6 in __gnu_norm::vector<bool, std::allocator<bool>
    ::operator= (this=0xbffff4c8, __x=@0xbffff5f0) at stl_bvector.h:709
    #7 0x00005d3a in __gnu_debug_def::vector<bool, std::allocator<bool>
    ::operator= (this=0xbffff4c8, __x=@0xbffff5f0) at debug/vector:100
    #8 0x00006eb4 in mysqlpp::Row::operator= (this=0xbffff4a0) at row.h:54
    #9 0x00001ef9 in main (argc=1, argv=0xbffff6f0) at /Users/grahamreitz/
    Development/Projects/tac/main.cpp:51
    Libstdc++'s debug mode is documented here:
    http://gcc.gnu.org/onlinedocs/libstdc++/debug.html#safe

    Xcode might have its own relevant docs you should also read.

    The code violates a precondition of std::copy() that isn't detected in
    release builds, but causes an assertion failure in debug mode.

    Jon

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupplusplus @
categoriesmysql
postedDec 4, '07 at 3:26a
activeJan 10, '08 at 4:08a
posts16
users3
websitemysql.com
irc#mysql

People

Translate

site design / logo © 2022 Grokbase