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
