Thorsten Glaser wrote:

...

...

Seems like there is some preprocessor work to do, but look at that locate output below. I have no idea why the file isn't found.

...

tg@odem:/home/tg/gpc-20030830/p/test $ locate gpc-in-c.h /usr/lib/gcc-lib/i386-ecce-mirbsd7/3.2.3/include/gpc-in-c.h

Does `gpc --print-file-name=include/gpc-in-c.h' find it?

tg@odem:/home/tg $ gpc --print-file-name=include/gpc-in-c.h /usr/lib/gcc-lib/i386-ecce-mirbsd7/3.2.3/include/gpc-in-c.h

Did you check the output of `gpc -v' (or can you send it)?

...

There's a small discrepancy in the time conversion (localtime() on the libc level). The given time corresponds to 02:19:48, but localtime returns 02:19:26. Maybe leap seconds? Are they supposed to be handled there (they're not on the system I've tested it on so far), hmm ...

According to POSIX, both the UNIX time (kernel) and the user time are set to UTC, that is, displaying lawful time (for us Germans, just add 3600 seconds to get lawful time). According to correctness, and described by djb,

Who or what is djb?

(xntpd including ntpdate is POSIXly broken, so no help.)

Just to be sure what we're talking about, is this going to be a holy war about different ways of handling leap seconds? If so, I think I'd prefer to follow POSIX (as most systems seem to). Or am I misunderstanding you?

Anyway, to cut it short, for this particular test, since it tests a fixed date in the past, I suppose we can be sure that there were exactly 22 leap seconds until then (since 1970-01-01), so if we treat both 48 and 26 as correct, will this be sufficient?

Frank