Re: Release works, Debug (still) crashes on OS X Leopard, Xcode 3.0

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@xxxxxxx
> >
> >
> > --
> > MySQL++ Mailing List
> > For list archives: http://lists.mysql.com/plusplus
> > To unsubscribe:    http://lists.mysql.com/plusplus?unsub=grahamreitz@xxxxxxx
>
>
> --
> MySQL++ Mailing List
> For list archives: http://lists.mysql.com/plusplus
> To unsubscribe:    http://lists.mysql.com/plusplus?unsub=grahamreitz@xxxxxxx