Re: Build failure for Emacs master

[Angelo Graziosi]

Il 12/04/2016 13:36, Phillip Lord ha scritto:
> Reappeared randomly, or reappeared consistently on every build?

I would say "periodically"..

I had this issue on March 5 but then I was able to build OB on March 12, 
23, 24, 29 and April 03. Now it reappeared... sometimes it fails with 
lisp/loaddefs.el and sometimes with other loaddefs. For example this 
evening:

[...]
In toplevel form:
../../emacs/lisp/gnus/gnus-icalendar.el:359:1:Error: End of file during 
parsing: 
c:/msys64/tmp/mingw-w64-emacs-git/src/emacs/lisp/org/org-loaddefs.el
Makefile:282: set di istruzioni per l'obiettivo 
"gnus/gnus-icalendar.elc" non riuscito
make[2]: *** [gnus/gnus-icalendar.elc] Errore 1
[...]

..and org/org-loaddefs.el seems to suffers the same issues of 
lisp/loaddefs.el I already flagged..

BTW, I notice that current build logs have a lot of "garbage" like this:

[...]
C:/msys64/tmp/mingw-w64-emacs-git/src/emacs/lib-src/ntlib.c:110:15: 
warning: format '%d' expects argument of type 'int', but argument 2 has 
type 'DWORD {aka long unsigned int}' [-Wformat=]

       printf ("Checking parent status failed: %d\n", GetLastError ());
[...]


and Emacs also shows a lot of ^M characters..

I think this garbage is related to the configure messages:

[...]
checking whether C compiler handles -W... yes
checking whether C compiler handles -Wabi... yes
checking whether C compiler handles -Waddress... yes
checking whether C compiler handles -Waggressive-loop-optimizations... yes
checking whether C compiler handles -Wall... yes
checking whether C compiler handles -Wattributes... yes
checking whether C compiler handles -Wbool-compare... yes
checking whether C compiler handles -Wbuiltin-macro-redefined... yes
[...]

Why enabling this by default? All this should be OFF by default and only 
the maintainers which need it should enable it

  Angelo


> Phil
>
> Angelo Graziosi <address@hidden> writes:
>
> > Just for the record...
> >
> > After about a month, the issue has reappeared.
> >
> > Now it fails with this message:
> >
> > [...]
> > Loading button...
> > Loading loaddefs.el (source)...
> > Wrong number of arguments: autoload, 1325
> > Makefile:540: set di istruzioni per l'obiettivo "emacs.exe" non riuscito
> > make[1]: *** [emacs.exe] Errore 127
> > make[1]: uscita dalla directory "/tmp/work/emacs-master/src"
> > Makefile:398: set di istruzioni per l'obiettivo "src" non riuscito
> > make: *** [src] Errore 2
> >
> > but the lisp/loaddefs.el seems to have the same defects..
> >
> > Ciao,
> >   Angelo.
> >
> > Il 05/03/2016 08:25, Eli Zaretskii ha scritto:
> > > > From: Angelo Graziosi <address@hidden>
> > > > Date: Fri, 4 Mar 2016 22:50:31 +0100
> > > >
> > > > $ cat ./src/emacs/lisp/loaddefs.el
> > > > [...]
> > > > (autoload 'xref-collect-matches "xref" "\
> > > > Collect matches for REGEXP inside FILES in DIR.
> > > > FILES is a string with glob patterns separated by spaces.
> > > > IGNORES is a list of glob patterns.
> > > >
> > > > \(fn REGEXP FILES DIR IGNORES)" nil nil)
> > > >
> > > > ;;;***
> > > >
> > > >
> > > > while for the others
> > > >
> > > > $ cat ./src/emacs/lisp/.../loaddefs.el
> > > > [...]
> > > > ;;;***
> > > >
> > > >
> > > > (provide 'loaddefs)
> > > > ;; Local Variables:
> > > > ;; version-control: never
> > > > ;; no-byte-compile: t
> > > > ;; no-update-autoloads: t
> > > > ;; coding: utf-8
> > > > ;; End:
> > > > ;;; loaddefs.el ends here
> > > >
> > > >
> > > > Maybe just retrying builds..
> > >
> > > Yes, this looks like the same problem.
> > >
> > > The challenge is to catch the instance when such a faulty loaddefs.el
> > > is produced, and see what happens there.  Ideas for how to do that are
> > > welcome.
> > >
> > > > In any cases this kind of failures are rather recent. I have built
> > > > master on MSYS2 for months without any failure and since, say, first
> > > > decade of February they occur..
> > >
> > > I've seen this first in last November.  Not sure if it's the same
> > > problem, but the symptoms are very similar.
> > >
> > > Are all of your builds full bootstraps in a fresh directory using a
> > > freshly cloned repository?