Re: [PATCH] PostgreSQL fails to build with 32bit MinGW-w64

On Sun, Dec 4, 2011 at 09:14, NISHIYAMA Tomoaki
<tomoakin(at)staff(dot)kanazawa-u(dot)ac(dot)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.

--
 Magnus Hagander
 Me: http://www.hagander.net/
 Work: http://www.redpill-linpro.com/