|
From: Tatsuro M. <tma...@ya...> - 2011-01-03 19:44:07
|
Hello
Thank you for immediate response and treatment.
Build on the Cygwin with the cvs source dated 2011-01-03 was successful.
Fine!!
> I've checked in a fix just now. Could you please test it? If it builds
> successfully, could you test the following command?
>
> print time(0),time(0.),time(" %Y/%m/%d %H:%M:%02.6S")
Cygwin
gnuplot> print time(0),time(0.),time(" %Y/%m/%d %H:%M:%02.6S")
347398005 347398005.468875 2011/01/03 19:26:45.468875
MinGW
gnuplot> print time(0),time(0.),time(" %Y/%m/%d %H:%M:%02.6S")
347398047 347398047.453125 2011/01/03 19:27:27.453125
DJGPP
gnuplot> print time(0),time(0.),time(" %Y/%m/%d %H:%M:%02.6S")
347430489 347430489.76 2011/01/04 04:28:09.760000
Note that the result in DJGPP is different from those in Cygwin and MinGW.
Perhaps DJGPP uses JST (Japanese Standard Time, UTC+9) and Cygwin and MinGW use UTC.
I do not know which you would like to implement.
> I apologize for the inconvenience.
No problem. One of the purpose of my frequently build of the CVS source is to kill the bug as soon as
possible. Faster finding issue is better for debugging.
Regards
Tatsuro
--- Peter Juhasz wrote:
> On Mon, Jan 3, 2011 at 11:40 AM, Tatsuro MATSUOKA
> <tma...@ya...> wrote:
> > Hello
> >
> > I have checked out the cvs source and tried to build it.
> >
> > 2011-01-02 �Peter Juhasz �<ju...@us...>
> >
> > � � � �* src/internal.c (f_time) docs/gnuplot.doc:
> > � � � �Modified time() so that type of result depends on type of
argument
> >
> >
> > gcc -shared-libgcc -DHAVE_CONFIG_H -I. -I.. �-I../term -I../term
-DBINDIR=\"/usr/local/bin\"
> > -DX11_DRIVER_DIR=\"/usr/local/libexec/gnuplot/4.5\"
> > -DGNUPLOT_PS_DIR=\"/usr/local/share/gnuplot/4.5/PostScript\"
> > -DGNUPLOT_JS_DIR=\"/usr/local/share/gnuplot/4.5/js\"
> > -DGNUPLOT_LUA_DIR=\"/usr/local/share/gnuplot/4.5/lua\"
> > -DCONTACT=\"gnu...@li...\"
> > -DHELPFILE=\"/usr/local/share/gnuplot/4.5/gnuplot.gih\" -DGNUPLOT_X11=\"`echo gnuplot_x11 |
> sed
> > 's,x,x,'`.exe\" -DXAPPLRESDIR=\"/etc/X11/app-defaults/\" �-I/usr/local/include �
-D_REENTRANT
> > -I/usr/include/cairo -I/usr/include/pixman-1 -I/usr/include/freetype2 -I/usr/include/libpng12
> > -I/usr/include/pango-1.0 -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include � �-O3
> > -fomit-frame-pointer -MT internal.o -MD -MP -MF .deps/internal.Tpo -c -o internal.o internal.c
> > internal.c: In function 'f_time':
> > internal.c:1452: error: storage size of 'tp' isn't known
> > make[3]: *** [internal.o] Error 1
> >
> >
> > On djgpp and MinGW, the builds were successful without errors.
> >
> > HMMM. On the source 2011-01-01, the cygwin build was carried out without problem. So this
> error comes
> > from newly imported code.
> >
> > f_time(union argument *arg)
> > {
> > � �struct value val, val2;
> > � �double time;
> > � �struct timeval tp; // <== line 1452
> >
> > Is timeval a origin of the error
> >
> > Any suggestions?
> >
> > Regards
> >
> > Tatsuro
> >
> >
> >
> > Any suggestions ?
> >
>
> The breakage was caused by me: I carelessly used the gettimeofday()
> function without realizing that it has to be included from sys/time.h.
> Apparently, on GNU systems the compiler manages to find the correct
> definition even without the missing #include statement - perhaps this
> is why your MinGW and djgpp builds proceeded without error, and this
> is why I noticed nothing. However, on other systems this is not so.
>
> I've checked in a fix just now. Could you please test it? If it builds
> successfully, could you test the following command?
>
> print time(0),time(0.),time(" %Y/%m/%d %H:%M:%02.6S")
>
> I apologize for the inconvenience.
>
> P�er Juh�z
>
--------------------------------------
Get the new Internet Explorer 8 optimized for Yahoo! JAPAN
http://pr.mail.yahoo.co.jp/ie8/
|