Build failure in gettimeofday

Build failure in gettimeofday

[martin rudalics]

Not having tried to build master for a couple of months with my
antediluvian Windows XP setup, compiling currently fails thusly:


make -C doc/lispref info
   CC       gettimeofday.o
make[2]: Entering directory `/c/emacs-git/trunk/dbg/doc/lispref'
   GEN      ../../../doc/lispref/../../info/elisp.info
../../lib/gettimeofday.c: In function 'gettimeofday':
../../lib/gettimeofday.c:63:46: error: 'GetSystemTimePreciseAsFileTime' undeclared (first use in this function)
  #  define GetSystemTimePreciseAsFileTimeFunc GetSystemTimePreciseAsFileTime
                                               ^
../../lib/gettimeofday.c:101:7: note: in expansion of macro 'GetSystemTimePreciseAsFileTimeFunc'
    if (GetSystemTimePreciseAsFileTimeFunc != NULL)
        ^
../../lib/gettimeofday.c:63:46: note: each undeclared identifier is reported only once for each function it appears in
  #  define GetSystemTimePreciseAsFileTimeFunc GetSystemTimePreciseAsFileTime
                                               ^
../../lib/gettimeofday.c:101:7: note: in expansion of macro 'GetSystemTimePreciseAsFileTimeFunc'
    if (GetSystemTimePreciseAsFileTimeFunc != NULL)
        ^
../../lib/gettimeofday.c:102:5: warning: implicit declaration of function 'GetSystemTimePreciseAsFileTime' [-Wimplicit-function-declaration]
      GetSystemTimePreciseAsFileTimeFunc (&current_time);
      ^
../../lib/gettimeofday.c:102:5: warning: nested extern declaration of 'GetSystemTimePreciseAsFileTime' [-Wnested-externs]
make[1]: *** [gettimeofday.o] Error 1
make[1]: Leaving directory `/c/emacs-git/trunk/dbg/lib'
make: *** [lib] Error 2
make: *** Waiting for unfinished jobs....


Help appreciated.

Thanks in advance, martin

Re: Build failure in gettimeofday

[Eli Zaretskii]

> From: martin rudalics <rudalics@gmx.at>
> Date: Wed, 9 Sep 2020 10:44:54 +0200
> 
> Not having tried to build master for a couple of months with my
> antediluvian Windows XP setup, compiling currently fails thusly:
> 
> 
> make -C doc/lispref info
>    CC       gettimeofday.o
> make[2]: Entering directory `/c/emacs-git/trunk/dbg/doc/lispref'
>    GEN      ../../../doc/lispref/../../info/elisp.info
> ../../lib/gettimeofday.c: In function 'gettimeofday':
> ../../lib/gettimeofday.c:63:46: error: 'GetSystemTimePreciseAsFileTime' undeclared (first use in this function)
>   #  define GetSystemTimePreciseAsFileTimeFunc GetSystemTimePreciseAsFileTime
>                                                ^
> ../../lib/gettimeofday.c:101:7: note: in expansion of macro 'GetSystemTimePreciseAsFileTimeFunc'
>     if (GetSystemTimePreciseAsFileTimeFunc != NULL)
>         ^
> ../../lib/gettimeofday.c:63:46: note: each undeclared identifier is reported only once for each function it appears in
>   #  define GetSystemTimePreciseAsFileTimeFunc GetSystemTimePreciseAsFileTime
>                                                ^

Doesn't happen here.  Which flavor of MinGW are you using, and what
are the values of _WIN32_WINNT and _WIN32_WINNT_WIN8 when compiling
lib/gettimeofday.c?

Re: Build failure in gettimeofday

[martin rudalics]

 > Which flavor of MinGW are you using, and what
 > are the values of _WIN32_WINNT and _WIN32_WINNT_WIN8 when compiling
 > lib/gettimeofday.c?

It's likely MinGW 4.8.1 with MSYS 1.0 but I do not recall the details
anymore.  After my old XP machine crashed and my Windows 10 install on
another machine refuses to boot, I'm on an XP machine that I only used
as backup but never for development.  So you'd also have to tell me
_where_ to look for the values of WIN32_WINNT and _WIN32_WINNT_WIN8.

Thanks, martin

Re: Build failure in gettimeofday

[Eli Zaretskii]

> Cc: emacs-devel@gnu.org
> From: martin rudalics <rudalics@gmx.at>
> Date: Mon, 14 Sep 2020 10:10:04 +0200
> 
>  > Which flavor of MinGW are you using, and what
>  > are the values of _WIN32_WINNT and _WIN32_WINNT_WIN8 when compiling
>  > lib/gettimeofday.c?
> 
> It's likely MinGW 4.8.1 with MSYS 1.0 but I do not recall the details
> anymore.  After my old XP machine crashed and my Windows 10 install on
> another machine refuses to boot, I'm on an XP machine that I only used
> as backup but never for development.  So you'd also have to tell me
> _where_ to look for the values of WIN32_WINNT and _WIN32_WINNT_WIN8.

I guess you mean GCC 4.8.1?

Please show the output of "gcc --version", and the version-related
macros in the _mingw.h header (under your system include directory).

Re: Build failure in gettimeofday

[martin rudalics]

 > Please show the output of "gcc --version", and the version-related
 > macros in the _mingw.h header (under your system include directory).

gcc --version
gcc (GCC) 4.8.1
Copyright (C) 2013 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

and _mingw.h with

#define __MINGW32_VERSION           3021000L
#define __MINGW32_MAJOR_VERSION           3
#define __MINGW32_MINOR_VERSION          21
#define __MINGW32_PATCHLEVEL              0

Grepping my MinGW tree doesn't find any trace of _WIN32_WINNT_WIN8.
And indeed backporting the

# if !(_WIN32_WINNT >= _WIN32_WINNT_WIN8)
   if (!initialized)
     initialize ();
# endif

chunk to a release build and running under gdb I get

Breakpoint 1, gettimeofday (tv=0x82f5f8, tz=0x0) at ../../lib/gettimeofday.c:92
92	  if (!initialized)
(gdb) p _WIN32_WINNT
$1 = 1024
(gdb) p _WIN32_WINNT_WIN8
No symbol "_WIN32_WINNT_WIN8" in current context.

The reason seems to be that the version of MinGW I'm using here has no
include/sdkddkver.h yet.  Sorry for the late check but my release
Emacs on this machine deliberately changes my keyboard layout from
German to American and I have no idea how to stop it from doing that.

martin

Re: Build failure in gettimeofday

[Eli Zaretskii]

> Cc: emacs-devel@gnu.org
> From: martin rudalics <rudalics@gmx.at>
> Date: Tue, 15 Sep 2020 10:06:48 +0200
> 
> Breakpoint 1, gettimeofday (tv=0x82f5f8, tz=0x0) at ../../lib/gettimeofday.c:92
> 92	  if (!initialized)
> (gdb) p _WIN32_WINNT
> $1 = 1024
> (gdb) p _WIN32_WINNT_WIN8
> No symbol "_WIN32_WINNT_WIN8" in current context.
> 
> The reason seems to be that the version of MinGW I'm using here has no
> include/sdkddkver.h yet.

OK, that explains everything.  Please try the latest master, I tried
to fix this.

(Gnulib seems to be in the process of abandoning Windows XP support,
because MinGW64 dropped it.  So some imports from Gnulib will probably
cause trouble in Emacs at some point on those old platforms.)

Re: Build failure in gettimeofday

[martin rudalics]

 > Please try the latest master, I tried
 > to fix this.

Thank you.  A -O0 -g3 build succeeds now but a -O3 build currently
fails thusly:

In file included from ../../src/emacs.c:68:0:
../../src/bignum.h:25:17: fatal error: gmp.h: No such file or directory
  #include <gmp.h>
                  ^
compilation terminated.
make[1]: *** [emacs.o] Error 1
make[1]: *** Waiting for unfinished jobs....
make[1]: Leaving directory `/c/emacs-git/trunk/opt/src'
make: *** [src] Error 2

My -O0 builds have, for historically reasons, also

-Wno-logical-op --Wno-missing-braces

and

--enable-checking=yes --enable-gcc-warnings=warn-only --enable-check-lisp-object-type=warn-only

but I doubt that these can be relevant.  Any clues?  A couple of
warnings from the -O0 build just in case they could hint at anything.

   CC       menu.o
../../src/xdisp.c: In function 'move_it_in_display_line_to':
../../src/xdisp.c:9557:10: warning: unknown conversion type character 't' in format [-Wformat=]
           IT_CHARPOS (*it));
           ^
../../src/xdisp.c:9557:10: warning: too many arguments for format [-Wformat-extra-args]
../../src/xdisp.c: In function 'move_it_to':
../../src/xdisp.c:9925:8: warning: unknown conversion type character 't' in format [-Wformat=]
         move_trace ("move_it: from %td\n", IT_CHARPOS (*it));
         ^
../../src/xdisp.c:9925:8: warning: too many arguments for format [-Wformat-extra-args]
../../src/xdisp.c:9928:8: warning: unknown conversion type character 't' in format [-Wformat=]
         move_trace ("move_it: to %td\n", IT_CHARPOS (*it));
         ^
../../src/xdisp.c:9928:8: warning: too many arguments for format [-Wformat-extra-args]
../../src/xdisp.c: In function 'move_it_vertically':
../../src/xdisp.c:10321:7: warning: unknown conversion type character 't' in format [-Wformat=]
        move_trace ("move_it_v: from %td, %d\n", IT_CHARPOS (*it), dy);
        ^
../../src/xdisp.c:10321:7: warning: too many arguments for format [-Wformat-extra-args]
../../src/xdisp.c:10324:7: warning: unknown conversion type character 't' in format [-Wformat=]
        move_trace ("move_it_v: to %td\n", IT_CHARPOS (*it));
        ^
../../src/xdisp.c:10324:7: warning: too many arguments for format [-Wformat-extra-args]

   CC       pdumper.o
../../src/pdumper.c: In function 'dump_queue_dequeue':
../../src/pdumper.c:1221:6: warning: unknown conversion type character 't' in format [-Wformat=]
       XHASH_TABLE (dump_queue->link_weights)->count);
       ^
../../src/pdumper.c:1221:6: warning: too many arguments for format [-Wformat-extra-args]
   CC       data.o
   CC       doc.o
../../src/data.c: In function 'bignum_arith_driver':
../../src/data.c:2821:9: warning: assignment from incompatible pointer type [enabled by default]
    accum = &mpz[0];
          ^
../../src/data.c:2843:13: warning: assignment from incompatible pointer type [enabled by default]
        accum = &mpz[0];
              ^
../../src/data.c: In function 'Flogcount':
../../src/data.c:3157:11: warning: assignment from incompatible pointer type [enabled by default]
     nonneg = &mpz[0];
            ^
   CC       editfns.o
   CC       callint.o
   CC       eval.o
   CC       floatfns.o
../../src/floatfns.c: In function 'rescale_for_division':
../../src/floatfns.c:374:10: warning: assignment from incompatible pointer type [enabled by default]
        pn = t;
           ^
../../src/floatfns.c:382:10: warning: assignment from incompatible pointer type [enabled by default]
        pn = t;
           ^

   CC       atimer.o
../../src/timefns.c: In function 'frac_to_double':
../../src/timefns.c:622:9: warning: assignment from incompatible pointer type [enabled by default]
        d = &mpz[1];
          ^
../../src/timefns.c:630:9: warning: assignment from incompatible pointer type [enabled by default]
        n = &mpz[0];
          ^
../../src/timefns.c: In function 'lisp_to_timespec':
../../src/timefns.c:923:21: warning: initialization from incompatible pointer type [enabled by default]
    mpz_t const *qt = q;
                      ^
../../src/timefns.c: In function 'time_arith':
../../src/timefns.c:1151:10: warning: assignment from incompatible pointer type [enabled by default]
     hzmin = hzmin1;
           ^
../../src/timefns.c: In function 'time_cmp':
../../src/timefns.c:1265:10: warning: assignment from incompatible pointer type [enabled by default]
        za = &mpz[0];
           ^
../../src/timefns.c:1266:10: warning: assignment from incompatible pointer type [enabled by default]
        zb = &mpz[1];
           ^

Thanks again, martin

Re: Build failure in gettimeofday

[Eli Zaretskii]

> Cc: emacs-devel@gnu.org
> From: martin rudalics <rudalics@gmx.at>
> Date: Wed, 16 Sep 2020 10:21:56 +0200
> 
> Thank you.  A -O0 -g3 build succeeds now but a -O3 build currently
> fails thusly:
> 
> In file included from ../../src/emacs.c:68:0:
> ../../src/bignum.h:25:17: fatal error: gmp.h: No such file or directory
>   #include <gmp.h>
>                   ^
> compilation terminated.
> make[1]: *** [emacs.o] Error 1

??? How did the -O0 build get past this problem?  Header file
inclusion doesn't depend on optimizations.  Are you sure you have a
clean working tree, devoid of stale object files?

Anyway, it sounds like you don't have GMP installed?  In that case,
running configure is supposed to create lib/gmp.h, and the above
inclusion in bignum.h is supposed to find it.  It works for me on a
system where there's no libgmp.  Do you have lib/gmp.h?  If you do,
then perhaps this is a compiler bug: it should be able to find that
file, because the compiler switches include "-I../lib".

If you don't have lib/gmp.h, then your tree is mis-configured somehow.

Or maybe this is another aspect of our less-than-ideal support for
out-of-tree builds.

> but I doubt that these can be relevant.  Any clues?  A couple of
> warnings from the -O0 build just in case they could hint at anything.
> 
>    CC       menu.o
> ../../src/xdisp.c: In function 'move_it_in_display_line_to':
> ../../src/xdisp.c:9557:10: warning: unknown conversion type character 't' in format [-Wformat=]
>            IT_CHARPOS (*it));
>            ^
> ../../src/xdisp.c:9557:10: warning: too many arguments for format [-Wformat-extra-args]
> ../../src/xdisp.c: In function 'move_it_to':
> ../../src/xdisp.c:9925:8: warning: unknown conversion type character 't' in format [-Wformat=]
>          move_trace ("move_it: from %td\n", IT_CHARPOS (*it));
>          ^
> ../../src/xdisp.c:9925:8: warning: too many arguments for format [-Wformat-extra-args]
> ../../src/xdisp.c:9928:8: warning: unknown conversion type character 't' in format [-Wformat=]

That's because of your ancient version of GCC.  You will have to live
with this.

> ../../src/data.c: In function 'bignum_arith_driver':
> ../../src/data.c:2821:9: warning: assignment from incompatible pointer type [enabled by default]
>     accum = &mpz[0];
>           ^
> ../../src/data.c:2843:13: warning: assignment from incompatible pointer type [enabled by default]
>         accum = &mpz[0];
>               ^

That's the usual noise with GCC 4.x when compiling mini-gmp.  I
reported this as a bug, but no one wants to fix it, so I guess us
providing mini-gmp is just a lip service, and you are advised to
install libgmp if you are annoyed enough by these warnings.

Re: Build failure in gettimeofday

[martin rudalics]

 > Anyway, it sounds like you don't have GMP installed?

Right.

 > In that case,
 > running configure is supposed to create lib/gmp.h, and the above
 > inclusion in bignum.h is supposed to find it.  It works for me on a
 > system where there's no libgmp.  Do you have lib/gmp.h?  If you do,
 > then perhaps this is a compiler bug: it should be able to find that
 > file, because the compiler switches include "-I../lib".
 >
 > If you don't have lib/gmp.h, then your tree is mis-configured somehow.

I didn't have it and according to its log, configure was aware of that.
For some reason, it didn't create lib/gmp.h though.  Removing the build
directory entirely and reconfiguring solved the problem.

 > That's the usual noise with GCC 4.x when compiling mini-gmp.  I
 > reported this as a bug, but no one wants to fix it, so I guess us
 > providing mini-gmp is just a lip service, and you are advised to
 > install libgmp if you are annoyed enough by these warnings.

They don't annoy me much (IIRC compiling with gcc 10 created many more
warnings).  What annoys me most are those spontaneous switches to an
American keyboard layout.  Do you have any idea what could cause them?
I've never seen them before on any system I used to work on.  Is there a
way to revert them from within Emacs?  Presently, I have to save my
state somehow, leave Emacs and restart it which is not a workable
solution.

martin

Re: Build failure in gettimeofday

[Eli Zaretskii]

> Cc: emacs-devel@gnu.org
> From: martin rudalics <rudalics@gmx.at>
> Date: Thu, 17 Sep 2020 10:14:15 +0200
> 
> What annoys me most are those spontaneous switches to an American
> keyboard layout.  Do you have any idea what could cause them?

I'm not sure I understand what are you talking about.  I don't think
you've mentioned these problems earlier in this discussion, or what
did I miss?

If I didn't miss anything, can you describe these spontaneous switches
in more detail?  What exactly happens, and under which conditions?

Re: Build failure in gettimeofday

[martin rudalics]

 >> What annoys me most are those spontaneous switches to an American
 >> keyboard layout.  Do you have any idea what could cause them?
 >
 > I'm not sure I understand what are you talking about.  I don't think
 > you've mentioned these problems earlier in this discussion, or what
 > did I miss?
 >
 > If I didn't miss anything, can you describe these spontaneous switches
 > in more detail?  What exactly happens, and under which conditions?

That my keyboard layout apparently switched from Austrian to American in
a rather spontaneous manner.  I now attribute this to the fact that an
American layout was specified for that machine and apparently Windows XP
caught a M-S prefixed key combination (or maybe some other one) before
Emacs was able to process it.  This never occurred to me before.  I now
removed that layout and hope to not see this problem any more.

So far sorry for the noise, martin

Re: Build failure in gettimeofday

[Eli Zaretskii]

> Cc: emacs-devel@gnu.org
> From: martin rudalics <rudalics@gmx.at>
> Date: Fri, 18 Sep 2020 09:48:26 +0200
> 
> That my keyboard layout apparently switched from Austrian to American in
> a rather spontaneous manner.  I now attribute this to the fact that an
> American layout was specified for that machine and apparently Windows XP
> caught a M-S prefixed key combination (or maybe some other one) before
> Emacs was able to process it.

Ah, yes.  Happens to me as well: holding Alt-Shift for too long, or
even releasing them before pressing them again for some Emacs command,
does cause the keyboard layout switch (actually, a language switch
event).  You need to watch out for that.

However in my case, fixing this takes another Alt-Shift press, I never
have to shut down Emacs.

Re: Build failure in gettimeofday

[martin rudalics]

 > Ah, yes.  Happens to me as well: holding Alt-Shift for too long, or
 > even releasing them before pressing them again for some Emacs command,
 > does cause the keyboard layout switch (actually, a language switch
 > event).  You need to watch out for that.

Aha.  And apparently it affects only the process whose window is
receiving input at the moment I type Alt-Shift.  Otherwise, restarting
Emacs would not have helped.

 > However in my case, fixing this takes another Alt-Shift press, I never
 > have to shut down Emacs.

Elementary.  But since I didn't know about that Alt-Shift peculiarity, I
would not have known about its cure either ...

Thanks, martin

Re: Build failure in gettimeofday

[Eli Zaretskii]

> Cc: emacs-devel@gnu.org
> From: martin rudalics <rudalics@gmx.at>
> Date: Fri, 18 Sep 2020 10:18:50 +0200
> 
>  > Ah, yes.  Happens to me as well: holding Alt-Shift for too long, or
>  > even releasing them before pressing them again for some Emacs command,
>  > does cause the keyboard layout switch (actually, a language switch
>  > event).  You need to watch out for that.
> 
> Aha.  And apparently it affects only the process whose window is
> receiving input at the moment I type Alt-Shift.  Otherwise, restarting
> Emacs would not have helped.

That's on XP, yes.  JFTR, Windows 10 changes the default to apply to
_all_ windows (one of the settings I had to hunt early on and disable,
because it makes absolutely no sense to me).