Dave Page wrote:
but the CRC is still different for some as-yet unknown reason...
Unknown because I wasn't fully grokking what it was a CRC of. Everything
looks good now :-)
/D
---(end of broadcast)---
TIP 1: if posting/reading through
Tom Lane wrote:
AFAIK, time_t is a Unix-ism, so it's pretty unlikely to be used in the
APIs of anything on Windows.
Oh, it is.
I guess my advice would be to see if we can define _USE_32BIT_TIME_T
in port/win32.h and make it go away that way. It'd definitely be nice
if MSVC and Mingw builds
On 12/7/07, Dave Page [EMAIL PROTECTED] wrote:
Tom Lane wrote:
AFAIK, time_t is a Unix-ism, so it's pretty unlikely to be used in the
APIs of anything on Windows.
Oh, it is.
It's confined to the C Runtime libraries, not part of the Windows API
proper. (Three exceptions: IP Helper uses the
Gregory Stark wrote:
This is because of (at least) two changes in the ABI between the runtimes used
by mingw and VC++. 1) Enums are apparently 8 bytes on VC++ but 4 bytes on
mingw and 2) time_t is 8 bytes on VC++ but 4 bytes on mingw.
For the record:
Mingw
=
WARNING:
In trying to run a benchmark comparing mingw with VC++ builds Dave discovered
that if you initdb with one and try to run with the other you get a message
saying incorrect checksum in control file rather than the more appropriate
and friendly database files are incompatible with server.
This is
Gregory Stark wrote:
This is because of (at least) two changes in the ABI between the runtimes used
by mingw and VC++.
1) Enums are apparently 8 bytes on VC++ but 4 bytes on mingw
They are 4 bytes here on my 32 bit WinXP machine with VS2005SP1.
2) time_t is 8 bytes on VC++ but 4 bytes on
Rainer Bauer [EMAIL PROTECTED] writes:
Gregory Stark wrote:
This is because of (at least) two changes in the ABI between the runtimes used
by mingw and VC++.
1) Enums are apparently 8 bytes on VC++ but 4 bytes on mingw
They are 4 bytes here on my 32 bit WinXP machine with VS2005SP1.
Oh, I
Gregory Stark wrote:
The looming problem is that you won't be able to use any libraries or 3rd
party tools which use time_t in their interface unless you build with the same
size time_t as they do. I don't know how're expected to find out that a .so
you're handed has a different size time_t.
But
Gregory Stark [EMAIL PROTECTED] writes:
Oh, I bet it's not the enum which is 8 bytes but that the time_t required
8-byte alignment so there's 4 bytes of padding before it.
That makes more sense --- I was having a hard time imagining why anyone
would need 64-bit enums, let alone why that would
