From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Angelo Graziosi Newsgroups: gmane.emacs.devel Subject: Re: Build failure for Emacs master Date: Tue, 12 Apr 2016 22:54:43 +0200 Message-ID: <570D6093.8010305@alice.it> References: <56CCD91E.6070507@alice.it> <83egc2ixji.fsf@gnu.org> <56CD798D.7060102@alice.it> <56CD8408.1000701@alice.it> <83wppuggb4.fsf@gnu.org> <56CE2CA7.5050906@alice.it> <83io1cg2pt.fsf@gnu.org> <56DA0327.2030009@alice.it> <83oaatxu72.fsf@gnu.org> <570C4307.6050907@alice.it> <87k2k3t5xb.fsf@russet.org.uk> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1460494511 22025 80.91.229.3 (12 Apr 2016 20:55:11 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 12 Apr 2016 20:55:11 +0000 (UTC) Cc: Eli Zaretskii , emacs-devel@gnu.org To: Phillip Lord Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Apr 12 22:55:03 2016 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1aq5Kw-00060n-4Y for ged-emacs-devel@m.gmane.org; Tue, 12 Apr 2016 22:55:02 +0200 Original-Received: from localhost ([::1]:57391 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aq5Kq-0002rT-ND for ged-emacs-devel@m.gmane.org; Tue, 12 Apr 2016 16:54:56 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:48957) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aq5Km-0002oQ-NF for emacs-devel@gnu.org; Tue, 12 Apr 2016 16:54:54 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aq5Kj-0002K9-Bz for emacs-devel@gnu.org; Tue, 12 Apr 2016 16:54:52 -0400 Original-Received: from smtp202.alice.it ([82.57.200.98]:31394) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aq5Kj-0002Jy-1n; Tue, 12 Apr 2016 16:54:49 -0400 Original-Received: from [192.168.1.101] (79.19.227.36) by smtp202.alice.it (8.6.060.43) (authenticated as angelo.graziosi@alice.it) id 5697B30A192D1388; Tue, 12 Apr 2016 22:54:47 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 In-Reply-To: <87k2k3t5xb.fsf@russet.org.uk> X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 82.57.200.98 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.org gmane.emacs.devel:202869 Archived-At: 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 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 >>>> 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? >>>