Gregory Stark wrote:
> "Magnus Hagander" <magnus@hagander.net> 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