Re: [PATCH] Bad timestamps on MinGW32

[Eli Zaretskii]

> From: Orgad Shaneh <orgads@gmail.com>
> Date: Wed, 2 Nov 2022 22:14:26 +0200
> Cc: bug-make@gnu.org
> 
> On Wed, Nov 2, 2022 at 7:04 PM Eli Zaretskii <eliz@gnu.org> wrote:
> > > Fix by enabling _stat64 also for MinGW.
> >
> > Thanks, but this cannot be done for all MinGW builds.  There's
> > mingw.org's MinGW (which is what I use), and its default is to use
> > 32-bit time_t values.  If you use this change with that MinGW, Make
> > will likely crash at run time, because various libraries it is linked
> > against use a different time_t in stat calls.
> 
> Hi, and thanks for the prompt reply.
> 
> Do you mean that __MINGW_USE_VC2005_COMPAT has no effect on this
> platform?

Indeed, it doesn't currently.  But I wouldn't count on that, some
future version could introduce it.

> Or that it doesn't support _stat64?

_stat64 _is_ supported, but it isn't the default.  So if a program
needs to use _stat64, it can only be safely linked against libraries
that were also compiled with stat redirected to _stat64, otherwise you
cannot safely pass 'struct stat' variables and pointers between the
program and those libraries.  And since _stat64 is not the default,
the chance that libraries against which you link used it is very
small, practically nil.

The same goes for MinGW64, btw: you can only safely redirect stat to
_stat64 there if MinGW64 does that by default.  (I think it does, but
I'm not sure.)

> > So this condition:
> >
> > > -#if defined(_MSC_VER) && _MSC_VER > 1200
> > > +#if defined(__MINGW32__) || (defined(_MSC_VER) && _MSC_VER > 1200)
> >
> > must be rewritten to catch only MinGW64 builds.  Which would mean a
> > more fine-grained testing of the value of __MINGW_MAJOR_VERSION etc.
> 
> I'll try to find something. But first I'll need an answer for the
> previous question, so I know which changes to look for in mingw.

I hope I answered them.