bug-make
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH] Bad timestamps on MinGW32


From: Eli Zaretskii
Subject: Re: [PATCH] Bad timestamps on MinGW32
Date: Thu, 03 Nov 2022 10:24:30 +0200

> From: Orgad Shaneh <orgads@gmail.com>
> Date: Thu, 3 Nov 2022 08:29:53 +0200
> Cc: bug-make@gnu.org
> 
> > > 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?

It is, albeit much less so than MinGW64.

> Where can I get it?

   https://osdn.net/projects/mingw/releases

> > _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?

For example, Guile and all its dependencies.

There's also libmingwex, which provides some functions the MS C
runtime doesn't have.  libmingwex is basically linked into every MinGW
program, since the MinGW startup calls some of those extra runtime
functions.

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

Are you sure 'struct stat' variables and pointers are never shared
with any libraries against which we link Make libraries?  How can you
be sure of that?  And even if today this is somehow true, will we
remember this tomorrow when we add new code to Make?

This is a time bomb waiting to go off.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]