Hello!
On Thu, 10 Dec 1998, Thomas G. Lockhart wrote:
> > I am sure this is related. When I edited config.h and commented out
> > DATEDEBUG the sources compiled just fine.
>
> So send my your config.h if you want someone to look at it.
I've solved this issue. I uncomment it to
#define DATEDEBUG but forget to add definition. After writing
#define DATEDEBUG 1 postgres compiled.
> > Any use for daylight or tzname or timezone (global vars) produces
> > incorrect results.
> > It looks like glibc2 defines these vars incorrectly. Correct values
> > are in struct tm (including tmzone and gmtoff).
> > Do you think it is local problem? I am pretty sure it is
> > "system-wide".
>
> The glibc2 is a thread-safe library, and I would expect that the *only*
> place with reliable timezone info is in the tm structure. Global
> variables are not to be trusted since they are not available in a
> reentrant way.
Yes, I understood the idea after you explained this for a first time.
> If the tm structure contains the timezone info (as it claims to on my
> RH5.1 glibc2 system) then for testing try to #undef HAVE_INT_TIMEZONE in
> config.h and see how it goes. If I have a chance tomorrow I'll try doing
> the same at work. I'm guessing that our configure tests look for the
> global variable version first, and that the glibc2 passes that test even
> though the other mechanism is the right one.
#undef HAVE_INT_TIMEZONE in config.h replaced by #define HAVE_INT_TIMEZONE 1
after configure. On the other hand, os.h (linked to port/linux.h) undefine it. I need to
test that it is still undefined when compiling datetime.c (and dt.c and all
that) - there are all provisions to use tm.tz_name/tm_gmtoff, compiler just
need right defines.
Oleg.
---- Oleg Broytmann National Research Surgery Centre http://sun.med.ru/~phd/ Programmers don't die, they
justGOSUB without RETURN.