Bug 611936 and the 2.4.0 release

[John Ralls]

On Nov 11, 2010, at 5:32 AM, Derek Atkins wrote:

> John Ralls <jralls at ceridwen.us> writes:
> 
>> On Nov 10, 2010, at 9:41 AM, Derek Atkins wrote:
>> 
>>> Phil Diacono <satphil at gmail.com> writes:
>>> 
>>>> This is also happening in Ubuntu 10.10 i386.  Bug "gnucash 2.3 with
>>>> sqlite retrieves all numbers as zero" reported to Ubuntu bugtracker
>>>> https://bugs.launchpad.net/ubuntu/+source/libdbi-drivers/+bug/673307
>>> 
>>> Hmm, perhaps we really need to work around a broken SQLite instead of
>>> depending on vendors not to build it in a "broken" configuration? 
>> 
>> It's not sqlite3, it's libdbi 0.8.3, and the problem occurs when you compile on certain systems without -nofastmath. 
>> 
>> How about putting a test in configure for the problem, so that when
>> the distro tries to build gnucash against a bad libdbi, configure will
>> fail with an appropriate message in config.log telling the user to go
>> rebuild libdbi with -nofastmath. Of course, if the libdbi integrator
>> isn't the same as the gnucash integrator (very likely), that will just
>> mean that there won't be a gnucash package unless or until the libdbi
>> integrator gets around to fixing the problem.
> 
> Is it really something that requires a rebuild of GnuCash?  I.e., if you
> build GnuCash against 0.8.3 built with -nofastmath, but then drop in a
> replacement 0.8.3 that was built WITHOUT -nofastmath, will GnuCash work
> or not?
> 
> If GnuCash would work in this situation then I do not believe that it
> should be a compile-time error because it also means the reverse could
> be true.  An update from a working version of libdbi to a broken build a
> libdbi would silently cause GnuCash to fail.
> 
>> Or we could lift the libdbi code and add it to our build. It gives us
>> more control, but the we miss out on libdbi's maintenance work unless
>> we're very diligent about keeping our "mirror" up to date.
> 
> Is there a runtime test we can perform to see if it's broken?  Or is
> there a way to work around the brokenness?
> 

I think Geert got his Fedora installation fixed by just rebuilding libdbi, so yes, the libdbi integrator could break it in an update and gnucash would break.

I suppose we could pretty easily insert a round-trip check (maybe at session startup on a sql backend?) that presents an error to the user. I'll see what I can do.

Regards,
John Ralls