Re: Build failure for Emacs master

[Angelo Graziosi <angelo.graziosi@alice.it>]

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 <angelo.graziosi@alice.it> 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 <angelo.graziosi@alice.it>
>>>> 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?
>>>