On Sun, Dec 4, 2011 at 09:14, NISHIYAMA Tomoaki
> 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
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.
In response to
pgsql-hackers by date
|Next:||From: Noah Misch||Date: 2011-12-04 12:20:27|
|Subject: Re: foreign key locks, 2nd attempt|
|Previous:||From: Magnus Hagander||Date: 2011-12-04 11:03:50|
|Subject: Re: Moving tablespaces|