Replacement for libdbi

John Ralls jralls at ceridwen.us
Sat Jan 11 18:46:40 EST 2014


On Jan 11, 2014, at 3:08 PM, Sébastien Villemot <sebastien at debian.org> wrote:

> Le samedi 11 janvier 2014 à 14:47 -0800, John Ralls a écrit :
> 
>>> If you can get libdbi to actually fix the time_t issue (and any other
>>> issues that we might be having) that would be great and obviate the need
>>> to fork the code.  Alas, right now they seem unwilling to acknowledge the
>>> existence of 32-bit Linux (and in particular 32-bit time_t).
>>> 
>>> I'm afraid it's not necessarily our job to make the lives of distribution
>>> maintainers easier, although we certainly try whenever we can!
>> 
>> We’d also need the libdbi package upgraded to 0.9; we need the transaction support. It’s currently 0.8.4, even in unstable.
> 
> I could certainly have libdbi upgraded to 0.9 in Debian unstable, if
> needed.
> 
> Concerning the time_t issue, I could carry a Debian-specific patch if
> that change was not modifying the ABI (but I guess it does on 32-bit
> archs). And anyways that would not fix the issue for other GNU/Linux
> distributions. I could however add my voice to convince libdbi
> developers. Is there a bug report to track this issue?

Yes, it was ref 1 on my original post: http://sourceforge.net/p/libdbi/bugs/15/

Time_t is a ‘long int’ in all GNU systems. See /usr/include/bits/types.h and typesizes.h. *BSD have their own type system and AFAIK they alone have 64-bit time_t. It can actually be read as a violation of POSIX, but I’m not sure that anyone much cares about that anymore. The actual fix would change not only ABI but API as well: The function is question, dbi_result_get_datetime() returns a time_t. The only reasonable fix that wouldn’t break existing code is to provide a second function that returns a struct tm.

There’s actually a workaround for that in libdbi-0.9.0, dbi_result_get_as_string_copy() which would allow us to pass the string to our own parser.

But I’d actually prefer to just switch to ODB. It’s C++ and it has better abstractions.

Regards,
John Ralls




More information about the gnucash-devel mailing list