Re: [PATCH] PostgreSQL fails to build with 32bit MinGW-w64 - Mailing list pgsql-hackers

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.


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
>> <tomoakin@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
thechecks in configure.in? I note it's turned off for MSVC in all flavors apparently. pgwin32_safestat() isn't safe for
largefiles anyway, so there would be good grounds for doing so quite apart from this, ISTM. (Of course, we should work
outhow 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
librariesyou 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
>