> From: Orgad Shaneh <org...@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 <e...@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.