Hi, If we are not to use 64 bit file size (and time), #undef stat may be sufficient. The #undef should be before the prototype of pgwin32_safestat because the #define stat _stat64 affect both the function and struct stat. The #undef stat necessitate #undef fstat as the parameter struct stat * is changed.
Additional change are for the macro redefinition warnings. (Suppress warnings, but perhaps not very different) The patch is tested to compile on x86_64-w64-mingw32-gcc 4.7.0 20111203 (experimental) and gcc version 4.6.1 on MingW/MSYS --- a/src/include/port.h +++ b/src/include/port.h @@ -334,6 +334,12 @@ extern bool rmtree(const char *path, bool rmtopdir); */ #if defined(WIN32) && !defined(__CYGWIN__) && !defined(UNSAFE_STAT_OK) #include <sys/stat.h> +#ifdef stat +#undef stat +#endif +#ifdef fstat +#undef fstat +#endif extern int pgwin32_safestat(const char *path, struct stat * buf); #define stat(a,b) pgwin32_safestat(a,b) If this is not sufficient, we might need to change all call of stat, lstat, and fstat to some wrapper functions? : It's theoretically doable, but could be quite difficult for a huge software.
pgsql-mingw64-patch.diff
Description: Binary data
On 2011/12/05, at 1:10, Andrew Dunstan wrote: > > > On 12/04/2011 06:31 AM, Magnus Hagander wrote: >> On Sun, Dec 4, 2011 at 09:14, NISHIYAMA Tomoaki >> <tomoa...@staff.kanazawa-u.ac.jp> wrote: >>> Hi, >>> >>> I found error on #define stat _stat64 occurs on Mingw-w64 >>> (x86_64-w64-mingw32) >>> gcc version 4.7.0 20111203 (experimental) (GCC) >>> >>> The code can be compiled with >>> >>> diff --git a/src/include/port.h b/src/include/port.h >>> index eceb4bf..78d5c92 100644 >>> --- a/src/include/port.h >>> +++ b/src/include/port.h >>> @@ -332,7 +332,7 @@ extern bool rmtree(const char *path, bool rmtopdir); >>> * Some frontends don't need the size from stat, so if UNSAFE_STAT_OK >>> * is defined we don't bother with this. >>> */ >>> -#if defined(WIN32)&& !defined(__CYGWIN__)&& !defined(UNSAFE_STAT_OK) >>> +#if defined(WIN32_ONLY_COMPILER)&& !defined(UNSAFE_STAT_OK) >>> #include<sys/stat.h> >>> extern int pgwin32_safestat(const char *path, struct stat * buf); >>> >>> but, surely we need to know if it is ok or not >>> as the comment before says: >>> * stat() is not guaranteed to set the st_size field on win32, so we >>> * redefine it to our own implementation that is. >>> >>> Is there any simple test program that determines if the pgwin32_safestat >>> is required or the library stat is sufficient? >>> I presume the stat is a library function and therefore it depends on the >>> compiler rather than the WIN32 platform as a whole. >> No, stat() is unreliable because it is implemented on top of >> FindNextFile(), and *that's* where the actual problem is at. And >> that's an OS API function, not a library function. See the discussion >> at http://archives.postgresql.org/pgsql-hackers/2008-03/msg01181.php >> >> In theory, if mingw implemented their stat() without using >> FindNextFile(), it might work - but I don't see how they'd do it in >> that case. And I can't see us going into details to remove such a >> simple workaround even if they do - it's better to ensure we work the >> same way with different compilers. >> > > > Yeah. > > > This is only a problem because, with this compiler, configure finds this: > > checking for _FILE_OFFSET_BITS value needed for large files... 64 > checking size of off_t... 8 > > whereas on the mingw-w64 compiler pitta is using it finds this: > > checking for _FILE_OFFSET_BITS value needed for large files... unknown > checking for _LARGE_FILES value needed for large files... unknown > checking size of off_t... 4 > > > It's the setting of _FILE_OFFSET_BITS that causes the offending macro > definition. > > Can we just turn off largefile support for this compiler, or maybe for all > mingw builds, possibly by just disabling the checks in configure.in? I note > it's turned off for MSVC in all flavors apparently. pgwin32_safestat() isn't > safe for large files anyway, so there would be good grounds for doing so > quite apart from this, ISTM. (Of course, we should work out how to handle > large files properly on Windows, but that's a task for another day.) > > (BTW, someone asked me the other day why anyone would want to do 32 bit > builds. One answer is that often the libraries you want to link with are only > available in 32 bit versions.) > > > cheers > > andrew > > -- > Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) > To make changes to your subscription: > http://www.postgresql.org/mailpref/pgsql-hackers >
-- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
