Re: Cannot complie internal.c of cvs source (2011-01-02) on Cygwin

[Peter J. <pet...@gm...>]

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éter Juhász