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. On 2011/12/04, at 12:55, NISHIYAMA Tomoaki wrote: > Hi, > > On 2011/12/04, at 9:45, Andrew Dunstan wrote: >>> Yes, but there's a deal more work to do here. This whole thing is falling >>> over in my build environment (64 bit Windows 7, MinGW/MSys, the machine >>> that runs pitta on the buildfarm.) >>> >>> This is a long way from a done deal. >> >> In particular, it's a major mess because it does this (or at least the >> version I'm using does): >> >> #define stat _stat64 >> >> which plays merry hell with pgwin32_safestat(). Working around that looks >> very unpleasant indeed. > > > Thank you for testing and reporting. > Would you mind giving me a bit more information on the environment? > --especially for the MinGW/MSYS versions and any other component that is > required. > > I tested on a virtual machine running 64 bit Windows 7 SP1, > installing MinGW/MSYS in the clean state and then compile. > The versions coming with pre-packaged repository catalogues of 20110802 > (gcc 4.5.2) and latest catalogue (gcc-4.6.1-2) compiles successfully. > > > On 2011/12/04, at 9:45, Andrew Dunstan wrote: > >> >> >> On 12/03/2011 06:12 PM, Andrew Dunstan wrote: >>> >>> >>> On 12/03/2011 09:59 AM, Magnus Hagander wrote: >>>> On Sat, Dec 3, 2011 at 15:49, NISHIYAMA Tomoaki >>>> <tomoa...@staff.kanazawa-u.ac.jp> wrote: >>>>> Hi, >>>>> >>>>>> Have you verified if tihs affects _MSC_VER< 1400? Suddently that >>>>>> branch would care about HAVE_CRTDEFS_H, and I'm not sure if that's >>>>>> something we need to worry about. >>>>> >>>>> I have no MSVC. In that sense it is not verified in fact, and I hope >>>>> those who knows well would kindly comment on it. >>>>> >>>>> However, it appears that pg_config.h is not created through >>>>> configure, but just copied from pg_config.h.win32 in those >>>>> compilers and thus HAVE_CRTDEFS_H will not be defined. >>>>> So, I think this code fragment will not be enabled in >>>>> _MSC_VER< 1400 >>>> Hmm, true. Unless HAVE_CRTDEFS_H is defined by the sytem, which it >>>> likely isn't - I was confusing it with the kind of defines that MSVC >>>> tends to stick in their own headerfiles, and thought that's what you >>>> were testing for. >>>> >>> >>> >>> Yes, but there's a deal more work to do here. This whole thing is falling >>> over in my build environment (64 bit Windows 7, MinGW/MSys, the machine >>> that runs pitta on the buildfarm.) >>> >>> This is a long way from a done deal. >> >> >> In particular, it's a major mess because it does this (or at least the >> version I'm using does): >> >> #define stat _stat64 >> >> >> which plays merry hell with pgwin32_safestat(). Working around that looks >> very unpleasant indeed. >> >> >> 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 >> > > > -- > Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) > To make changes to your subscription: > http://www.postgresql.org/mailpref/pgsql-hackers > -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
