On Thu, Sep 02, 1999 at 10:24:45AM -0400, avenger wrote:
> In file included from avenus.c:63:
> /root/coda/include/cfs/coda.h:266: field `va_atime' has incomplete type
> /root/coda/include/cfs/coda.h:267: field `va_mtime' has incomplete type
> /root/coda/include/cfs/coda.h:268: field `va_ctime' has incomplete type
> make[2]: *** [avenus.o] Error 1
> make[2]: Leaving directory `/root/coda/coda-src/auth2'
> make[1]: *** [auth2] Error 2
> make[1]: Leaving directory `/root/coda/coda-src'
> make: *** [coda-src] Error 2

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

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?

> It is probably a safe bet that it is the difference between glibc and
> libc5.  Current I am not messing with glibc on this machine because I know
> it'll be hours of work to changeover on this machine.  I do know that the
> new dist of slak5 which is in beta should be fully glibc, and if it's the
> case that all of these problems are related to that, then I will download
> the new dist and test it on my other machine.

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).

> --Aaron

Jan