This is the mail archive of the
mailing list for the Java project.
Re: libjava configuration problems
- To: Warren Levy <warrenl at redhat dot com>
- Subject: Re: libjava configuration problems
- From: Richard Earnshaw <rearnsha at arm dot com>
- Date: Fri, 26 Jan 2001 13:39:06 +0000
- cc: Richard Earnshaw <rearnsha at arm dot com>, Tom Tromey <tromey at redhat dot com>, gcc-bugs at gcc dot gnu dot org, java-discuss at sources dot redhat dot com
- Organization: ARM Ltd.
- Reply-To: rearnsha at arm dot com
> On 24 Jan 2001, Tom Tromey wrote:
> > >>>>> "Richard" == Richard Earnshaw <firstname.lastname@example.org> writes:
> > Richard> Actually, this is wrong, the test did fail. So why does
> > Richard> natSystem.cc still try to use 'timezone'?
> > It didn't used to. However, Warren's rewrite the timezone code seems
> > to have changed this.
> > Warren, can you look into this? I don't recall what the old code did
> > (but I'm sure cvs does :-), but it is definitely important to use the
> > results of configure.
> Actually, nothing changed; it has been this way (even when the code was in
> java/util/natTimeZone.cc). I wrote that code when I converted the
> corresponding JNI code in Classpath to a CNI routine. Classpath doesn't
> seem to check for this issue.
> Richard, I think the attached patch will do the trick. It builds and
> doesn't cause any regressions on my x86 linux box. Please see if it takes
> care of the problem on yours.
Thanks this compiles OK now (with a few other nit-bits -- mainly standard
porting issues -- I'm now running the regression tests for libjava).
An idea for your final fallback (where you currently set tzoffset to 0 is
to use difftime to get the time difference from gmtime(). Although this
returns a double we shouldn't loose any precission since the maximum diff
should be at most 13 Hours including DST.
> + // FIXME: there must be another global if neither tm_gmtoff nor timezone
> + // is available, esp. if tzname is valid.
> + tzoffset = 0;