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