Building on Windows from scratch - datediff problem found

John Ralls jralls at ceridwen.us
Thu Jan 23 17:47:52 EST 2014


On Jan 23, 2014, at 7:23 AM, Gary Bilkus <mail at gary.bilkus.com> wrote:

> I've done some more testing and found a problem with libofx and possibly aqbanking ( which I don't use ). It's easy enough to work round, but I'm not sure what the correct fix should be on Windows
> 
>  
> The problem is that there's a known issue with datediff and mingw, due to differences in the versions of MSCVRT used by mingw as to whether they expect time_t to be 32 or 64 bits.
> 
>  
> If you know you are compiling for Windows 7, you can get it to work by explicitly setting the windows version appropriately, so that it will use the 64 bit versions of time_t ( even on 32 bit windows ). However, I suspect that compiling that way won't work on XP which doesn't have the 64 bit version.
> 
>  
> There is lots of noise about this issue in various forums, but no clear answer what the 'correct' solution is if you want to be able to compile on any supported Windows version, and ideally get a package which works everywhere as well.
> 
>  
> Anyone have any good ideas how to fix this cleanly. The least bad solution might be simply to replace datediff with a simple subtraction, which should work for the cases it's used in libofx. But other dependencies might be different.
> 

Are you perhaps thinking of “difftime”? DATEDIFF is a SQL function; difftime is a standard C Library function.

This bug seems to be what you’re talking about: http://sourceforge.net/p/mingw/bugs/2152/, linked from http://mingw.5.n7.nabble.com/difftime-broken-td33080.html.

So Microsoft has invented a new twist on the 32-bit vs. 64-bit time_t problem by having both and a rather graceless way of determining which to use. In GnuCash we finessed that by not using the standard C functions because we need 64-bit time_t regardless of whether the platform provides it. We’re currently using Glib functions that don’t use it; soon we’ll switch to Boost functions that don’t use it either. 

It looks to from the bug that you have it backwards: You need to coerce 32-bit time_t because MinGW is screwed up and only calls difftime32() regardless of the size of time_t. That means that you can’t build GnuCash with MinGW wsl>=4.0 on a Win64 system until they fix the bug, or unless AQBanking and LibOFX work around the bug by replacing difftime with a subtraction-and-cast.

Regards,
John Ralls




More information about the gnucash-devel mailing list