On Thu, 2 Sep 1999, Jan Harkes wrote:

> struct timespec is not defined.. Should have been defined in
> /usr/include/time.h, and is part of the POSIX.1b spec.

Actually it is defined in libc5 but it's just "struct timespec;" :)
I looked on a glibc box and noticed there are quite a few more lines with
timespec in them than there are in my time.h.  

> Looking at the coda.h header, it is already defines this struct inside
> some cases, i.e. KERNEL and __CYGWIN32__. It looks like the glibc
> headers do a #define __timespec_defined whenever struct timespec has
> been defined. So I could do:
> 
> - #ifdef __CYGWIN32__
> + #if !defined(__timespec_defined)
>   #define __timespec_defined
>   struct timespec {
> 	time_t tv_sec;  /* seconds */
> 	long   tv_nsec; /* nanoseconds */
>   };
>   #endif
>     
> But can we rely on non-glibc posix-compliant headers to handle it the
> same way. As this header is also used by the kernel code, I can't really
> use autoconf to fix things like this. Or maybe.. autoconf could define
> HAVE_TIMESPEC, and we would assume that any non-kernel code must include
> config.h _before_ including coda.h, instead of including config.h from
> here.
> 
> Any opinions?

Really I wish I knew C and C++ so Ihad a better grasp on what goes on
between those things.  I tried to change the coda.h the was you have it up
there in the dist include file and remake the whole thing but then you get
a error about it being redefined, probably since it is defined in time.h,
just not the same way it is in glibc.

> Well, it's either several hours to change over the machine, or several
> hours compiling Coda while trying to find more types that aren't defined
> by libc5. Although correctly fixing some of the missing types might
> actually lead to a much cleaner code-base (like this timespec thing).

Really we should be close to the end though.  This error is fairly close
to the end of the compile from what I see of the directory structure,
although I've been known to be wrong at times. 

--Aaron