List:MySQL++« Previous MessageNext Message »
From:Graham Reitz Date:November 28 2007 1:02am
Subject:Re: Query object seg. faults on destruction...
View as plain text  
Thanks Warren,

> The more I think about it, the more I like this hypothesis, because  
> I don't see how you can link MySQL++ against a static MySQL library  
> without changing mysql++.bkl.  You're just not given the option to  
> do it any other way.

I will play with building the mysql and mysql++ libraries.    
Unfortunately, the fink package library server has been down since the  
18th.  So I am not sure if I can get fink to work w/o that.  I have it  
installed, which is good.

graham

On Nov 27, 2007, at 4:35 PM, Warren Young wrote:

> Graham Reitz wrote:
>> I made a little bit of progress.  I was statically linking the  
>> libmysqlclient_r.a and dynamically linking the mysqlpp library.   
>> When I dynamically linked both the memory alignment message is no  
>> longer present.
>> Although, I don't understand why it should matter.
>
> Lo, a crack of light doth shine 'pon the wreckage.  Perhaps you  
> built MySQL++ against the C API dynamic library, then linked your  
> test program against the static version?  This would result in two  
> copies of all MySQL routines in the final binary, and more  
> importantly, a mixture of data structures from one or the other,  
> depending on whether they're created by code within MySQL++ or  
> whether they don't get instantiated until your test program is built.
>
> The more I think about it, the more I like this hypothesis, because  
> I don't see how you can link MySQL++ against a static MySQL library  
> without changing mysql++.bkl.  You're just not given the option to  
> do it any other way.
>
> Other than that, I don't see why mixing linkage types should  
> matter.  As long as you're consistent in what type of each library  
> is linked throughout the project, it shouldn't care.  This is GCC  
> after all.
>
>> I should probably go ahead and build Fink,
>
> It's not as hard or time-consuming as you might think.
>
> One of my biggest complaints about Fink is that it seems to build a  
> lot of stuff from source even if you tell it to prefer binaries, so  
> going with the purely source-bootstrapped version seems like a  
> difference without a distinction.
>
> -- 
> MySQL++ Mailing List
> For list archives: http://lists.mysql.com/plusplus
> To unsubscribe:    http://lists.mysql.com/plusplus?unsub=1
>

Thread
Is method "const ColData Row::at(size_type i) const" leaking memory?Thunder021 Nov
  • Re: Is method "const ColData Row::at(size_type i) const" leakingmemory?Warren Young22 Nov
Re: Is method "const ColData Row::at(size_type i) const" leaking memory?Thunder026 Nov
  • Re: Is method "const ColData Row::at(size_type i) const" leakingmemory?Warren Young26 Nov
    • Re: Is method "const ColData Row::at(size_type i) const" leaking memory?Graham Reitz27 Nov
      • Re: Query object seg. faults on destruction...Graham Reitz27 Nov
        • Re: Query object seg. faults on destruction...Warren Young27 Nov
          • Re: Query object seg. faults on destruction...Graham Reitz27 Nov
            • Re: Query object seg. faults on destruction...Warren Young27 Nov
              • Re: Query object seg. faults on destruction...Graham Reitz28 Nov
Re: Is method "const ColData Row::at(size_type i) const" leaking memory?Thunder027 Nov
  • Re: Is method "const ColData Row::at(size_type i) const" leakingmemory?Warren Young27 Nov
Re: Is method "const ColData Row::at(size_type i) const" leaking memory?Thunder028 Nov
  • Re: Is method "const ColData Row::at(size_type i) const" leakingmemory?Warren Young28 Nov