[RFA] confine _TIMEVAL_DEFINED guard in libc/include/sys/time.h
Mon Nov 12 17:52:00 GMT 2012
On Nov 12 10:20, Christopher Faylor wrote:
> On Mon, Nov 12, 2012 at 11:40:31AM +0100, Corinna Vinschen wrote:
> >On Nov 11 13:58, Christopher Faylor wrote:
> >> The _TIMEVAL_DEFINED guard in time.h is a little to enthusiastic in what
> >> it is guarding. It's possible that there are other guards needed here
> >> but, IMO, _TIMEVAL_DEFINED shouldn't be turning off the declaration of
> >> timezone. Without this change, using Mingw64 headers becomes
> >> problematic.
> >> Ok to apply?
> >More or less, yes. The Mingw64 header uses the _TIMEVAL_DEFINED guard
> >also to guard the macros timerisset, timercmp, and timerclear, so we
> >should do the same. Would you mind to add that?
> Well, maybe, but that isn't a necessary change as far as getting 32-bit
> Cygwin building is concerned*. Although I can see the sense in putting
> the macros under this conditional, the macros on Linux are not protected
> by the equivalent "__need_timeval".
It's not really equivalent. The __need_timeval is used to pull in
only the timeval definition from other headers, while the newlib
_TIMEVAL_DEFINED macro has been explicitely added to handle inclusion
of Windows headers.
> Also, moving the macros has
> potential side-effects for rtems. Do they have to weigh in on this too?
Since _TIMEVAL_DEFINED is not defined anywhere else, no other target
should be affected, afaics.
> I thought this was an obvious change architecturally for newlib since
> the guard (or at least the naming of the guard) was clearly wrong.
> Moving the macros seems slightly less obvious.
> *I've had to make a number of changes to Cygwin to get it to build with
> the latest released version of the mingw64 headers.
What changes? I'm using the cygwin-w32api-headers-2.0.999-1.trunk.20121016
header package on Fedora, and I can build and run Cygwin fine after the
change from yesterday. Do the latest headers from the distro differ?
More information about the Newlib