This sounds too broken to be true, so this must be a pilot error...
After Configuring/Building and Installing Gcc 2-95.2 from Edition 15 of
FSF, patching glibc (using glibc-2.2-5.i686.rpm), the following program
fails to compile:
int main(int argc, char *argv)
struct timeval tv;
struct timezone tz;
std::cout << "TimeVal: " << tv.tv_sec
<< " " << tv.tv_usec
<< " TimeZone: " << tz.tz_minuteswest
<< " " << tz.tz_dsttime
The error is inside sys/time.h inside the prototype for gettimeofday.
#if defined __USE_GNU || defined __USE_BSD
typedef struct timezone * __timezone_ptr_t;
typedef void * __timezone_ptr_t;
/* Get the current time of day and timezone information,
putting it into *TV and *TZ. If TZ is NULL, *TZ is not filled.
Returns 0 on success, -1 on errors.
NOTE: This form of timezone information is obsolete.
Use the functions and variables declared in <time.h> instead. */
extern int gettimeofday(struct timeval *__restrict __tv,
__timezone_ptr_t __restrict __tv) __THROW;
The second parameter confuses gcc with the following error message
/usr/include/sys/time.h:77: two or more data types in declaration of `__tv`
(the line nb may be different).
However if instead of defining a __timezone_ptr_t you simply define a
__timezone__t which goes via the same typedef but does not includes the
pointer declaration (*), and explicitly add the pointer specification
before the __restrict, the you have no problem. Gcc compiles and the
program runs. Note that I compiled with and without -D__USE_GNU, I also
I do not beleive that such an commonly used function could fail so simply.
Given that dropped from my RedHat 7.0 gcc 2.96 I cannot tell if this would
have compiled under it (one would assume so). My guess is that I do not
have the matching set of include file for the benefit of 2-95.2. Indeed
performing a grep on time.h from / I can see that under
/usr/i386-glic21-linux/include/sys/time.h I have headers which would have
compiled correctly, however since I am using glibc2.2-5 (see above patch) I
should not be affected, besides this is a compilation problem isn't it ?
What does rpm -q glibc-devel tell you?
The stuff you cite from sys/time.h looks like content of glibc-2.1.92-*,
and was changed in early September to work around bugs in gcc 2.95.x
(the code is perfectly valid C, just 2.95.x does not cope with it well).