Re: BUG #15858: could not stat file - over 4GB
От | Tom Lane |
---|---|
Тема | Re: BUG #15858: could not stat file - over 4GB |
Дата | |
Msg-id | 19504.1566596960@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: BUG #15858: could not stat file - over 4GB (Juan José Santamaría Flecha <juanjo.santamaria@gmail.com>) |
Ответы |
Re: BUG #15858: could not stat file - over 4GB
Re: BUG #15858: could not stat file - over 4GB |
Список | pgsql-bugs |
=?UTF-8?Q?Juan_Jos=C3=A9_Santamar=C3=ADa_Flecha?= <juanjo.santamaria@gmail.com> writes: > On Wed, Jun 26, 2019 at 4:23 AM Michael Paquier <michael@paquier.xyz> wrote: >> It seems to me that you don't need the configure changes. > The changes in configuration are meant for gcc compilations in Windows > (Cygwin and Mingw). Directly editing the configure script is Not Done ... or at least, such changes wouldn't survive the next correctly-done configure update. You have to edit configure.in (or one of the sub-files in config/) and then regenerate configure using autoconf. It seems likely that we *don't* need or want this for Cygwin; that should be providing a reasonable stat() emulation already. So probably you just want to add "AC_LIBOBJ(win32_stat)" to the stanza beginning # Win32 (really MinGW) support if test "$PORTNAME" = "win32"; then AC_CHECK_FUNCS(_configthreadlocale) AC_REPLACE_FUNCS(gettimeofday) AC_LIBOBJ(dirmod) I'd also recommend that stat() fill all the fields in struct stat, even if you don't have anything better to put there than zeroes. Otherwise you're just opening things up for random misbehavior. I'm not in a position to comment on the details of the conversion from GetFileAttributesEx results to struct stat, but in general this seems like a reasonable way to proceed. regards, tom lane
В списке pgsql-bugs по дате отправления: