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 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
>