On Wed, Nov 2, 2022 at 4:15 PM Orgad Shaneh <org...@gmail.com> wrote: > > 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? Or that it doesn't support _stat64? Or something else? > > > 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.
You might also be interested in __MINGW64__. I don't think it's a good idea to try to use MinGW or compiler versions as a proxy for 32- or 64-bit time_t. Things are in flux to fix the y2038 problem. The debian-arm and debian-powerpc lists are having discussions about it now. You will surely encounter 64-bit time_t on 32-bit machines eventually. A first class configure test that checks for the size of time_t will probably be your best choice. Jeff