List:MySQL++« Previous MessageNext Message »
From:Graham Reitz Date:December 6 2007 11:23pm
Subject:Re: Release works, Debug (still) crashes on OS X Leopard, Xcode 3.0
View as plain text  
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
>


Thread
Release works, Debug (still) crashes on OS X Leopard, Xcode 3.0 (Part 2)Graham Reitz4 Dec
  • Re: Release works, Debug (still) crashes on OS X Leopard, Xcode 3.0 (Part 2) [SOLVED]Graham Reitz5 Dec
    • Re: Release works, Debug (still) crashes on OS X Leopard, Xcode 3.0 (Part 2) [SOLVED]Graham Reitz5 Dec
    • Re: Release works, Debug (still) crashes on OS X Leopard, Xcode 3.0(Part 2) [SOLVED]Warren Young5 Dec
      • Re: Release works, Debug (still) crashes on OS X Leopard, Xcode 3.0 (Part 2) [SOLVED]Jonathan Wakely5 Dec
        • Re: Release works, Debug (still) crashes on OS X Leopard, Xcode 3.0 (Part 2) [SOLVED]Graham Reitz5 Dec
          • Re: Release works, Debug (still) crashes on OS X Leopard, Xcode 3.0 (Part 2) [SOLVED]Jonathan Wakely6 Dec
          • Re: Release works, Debug (still) crashes on OS X Leopard, Xcode 3.0(Part 2) [SOLVED]Warren Young6 Dec
            • Re: Release works, Debug (still) crashes on OS X Leopard, Xcode 3.0 (Part 2) [SOLVED]Graham Reitz6 Dec
              • Re: Release works, Debug (still) crashes on OS X Leopard, Xcode 3.0Graham Reitz6 Dec
                • Re: Release works, Debug (still) crashes on OS X Leopard, Xcode 3.0Graham Reitz7 Dec
                  • Re: Release works, Debug (still) crashes on OS X Leopard, Xcode 3.0Graham Reitz7 Dec
                    • Re: Release works, Debug (still) crashes on OS X Leopard, Xcode 3.0Graham Reitz7 Dec
              • Re: Release works, Debug (still) crashes on OS X Leopard, Xcode 3.0 (Part 2) [SOLVED]Jonathan Wakely7 Dec
              • Re: Release works, Debug (still) crashes on OS X Leopard, Xcode 3.0(Part 2) [SOLVED]Warren Young10 Jan
  • Re: Release works, Debug (still) crashes on OS X Leopard, Xcode 3.0 (Part 2)Jonathan Wakely5 Dec