Re: [PATCH] Bad timestamps on MinGW32

[Orgad Shaneh]

On Thu, Nov 3, 2022 at 8:07 AM Eli Zaretskii <eliz@gnu.org> wrote:
>
> > 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.

Is mingw.org still active? Where can I get 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.

* Which libraries?
* Why should we care what other libraries do? Do we pass struct stat
to other libraries, or only to system functions?

- Orgad