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

[Graham Reitz]

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