Gregory Stark wrote:
"Magnus Hagander" <[EMAIL PROTECTED]> writes:
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 weren't binary-incompatible.
The attached patch defines it in the MSVC project files along with the
other API-config related macros. It fixes all the offsets so they match
mingw, but the CRC is still different for some as-yet unknown reason...
Is the project file really the proper place? Consider an add-on module -
wouldn't we want the setting to go in that one as well? meaning we'd have it in
a header file instead?
For an add-on module which is actually using time_t to interface with Postgres
it had better define _USE_... itself or else it risks having some files use
them and some not.
Yeah, that was roughly my thinking having run into exactly that problem
whilst playing around earlier. We also have other 'api config' macros in
project files (though I appreciate those aren't changing ABI related
stuff) so it seemed a natural place.
My other thought was that many of the addons this is likely to affect
will be packaged as additional contrib modules, so they will
automatically pickup the macro if dropped in /contrib and built from there.
An alternative is leaving it in the project file but putting something like
this in c.h:
#ifdef WIN32
#ifndef _USE_32BIT_TIME_T
#error "Postgres uses 32 bit time_t add #define _USE_32BIT_TIME_T on Windows
#endif
#endif
For modules which *do* use time_t this is safer. However for modules which
don't use time_t it'll be an unnecessary hassle.
Yeah, that might be useful. We could narrow the scope of platforms
affected by using _MSC_VER instead of WIN32.
/D
---------------------------(end of broadcast)---------------------------
TIP 3: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faq
