From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.bugs Subject: bug#18302: MSYS2 build issues Date: Thu, 21 Aug 2014 17:30:59 +0300 Message-ID: <83tx55c3to.fsf@gnu.org> References: <83zjezb00n.fsf@gnu.org> <83y4ujaxiv.fsf@gnu.org> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8BIT X-Trace: ger.gmane.org 1408631549 4768 80.91.229.3 (21 Aug 2014 14:32:29 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 21 Aug 2014 14:32:29 +0000 (UTC) Cc: chriszheng99@gmail.com, 18302@debbugs.gnu.org To: Karol Ostrovsky Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Thu Aug 21 16:32:23 2014 Return-path: Envelope-to: geb-bug-gnu-emacs@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 1XKTPZ-0004XG-D0 for geb-bug-gnu-emacs@m.gmane.org; Thu, 21 Aug 2014 16:32:21 +0200 Original-Received: from localhost ([::1]:60972 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XKTPZ-0007JM-0W for geb-bug-gnu-emacs@m.gmane.org; Thu, 21 Aug 2014 10:32:21 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:44098) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XKTPP-0007Bn-1o for bug-gnu-emacs@gnu.org; Thu, 21 Aug 2014 10:32:16 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XKTPG-0001UO-Uc for bug-gnu-emacs@gnu.org; Thu, 21 Aug 2014 10:32:11 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:42096) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XKTPG-0001UI-SO for bug-gnu-emacs@gnu.org; Thu, 21 Aug 2014 10:32:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1XKTPG-0003wg-Dd for bug-gnu-emacs@gnu.org; Thu, 21 Aug 2014 10:32:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 21 Aug 2014 14:32:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 18302 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: moreinfo Original-Received: via spool by 18302-submit@debbugs.gnu.org id=B18302.140863147415102 (code B ref 18302); Thu, 21 Aug 2014 14:32:02 +0000 Original-Received: (at 18302) by debbugs.gnu.org; 21 Aug 2014 14:31:14 +0000 Original-Received: from localhost ([127.0.0.1]:49039 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1XKTOQ-0003vP-EY for submit@debbugs.gnu.org; Thu, 21 Aug 2014 10:31:14 -0400 Original-Received: from mtaout24.012.net.il ([80.179.55.180]:38120) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1XKTON-0003uu-2r for 18302@debbugs.gnu.org; Thu, 21 Aug 2014 10:31:08 -0400 Original-Received: from conversion-daemon.mtaout24.012.net.il by mtaout24.012.net.il (HyperSendmail v2007.08) id <0NAN00P00UQTA700@mtaout24.012.net.il> for 18302@debbugs.gnu.org; Thu, 21 Aug 2014 17:26:27 +0300 (IDT) Original-Received: from HOME-C4E4A596F7 ([87.69.4.28]) by mtaout24.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NAN00G7DUS31790@mtaout24.012.net.il>; Thu, 21 Aug 2014 17:26:27 +0300 (IDT) In-reply-to: X-012-Sender: halo1@inter.net.il X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 140.186.70.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:92566 Archived-At: > Date: Thu, 21 Aug 2014 12:08:08 +0200 > From: Karol Ostrovsky > Cc: Glenn Morris , Chris Zheng , 18302@debbugs.gnu.org > > 1. I am the sole author of these changes. I have no issue with > signing the required legal papers. Please, let me know how to proceed > with this. Glenn, could you please send him the papers? > 2. MSYS2 'uname' is indeed the main source of the problem. My > solution fixes that, and also renames opsys=mingw32 to opsys=mingw. > This renaming is not strictly necessary, but I believe it is a good > practice to name things as clearly as possible. In this case, the > name mingw32 seems too related to a 32-bit system, which it is not any > more after my changes. I see no reason to change "mingw32" into something else. It's just a string, and doesn't imply anything about the bit-ness of the build. In fact, users who build Emacs will never see this string. Besides, MinGW64 tools can also be used to build a 32-bit Emacs. So let's leave that part alone. > 3. "-mtune" change: I don't see how Pentium4 optimisations are related > to running Windows9X. I know people still running Windows95 on > Pentium III. "-mtune=pentium4" does not mean that Pentium III is not supported. It just means the code is tuned better for Pentium 4. Without this switch, newer versions of GCC will use -mtune=native, which is certainly bad news for users of much older CPUs. > Shouldn't the official Emacs build be as generic as possible? Hard to answer that without knowing what you mean by "generic" in this context. Again, users who want to build Emacs only for themselves can always specify -mtune=native at configure time. > Perhaps one should even take away the whole -mtune part for MinGW. See above: it is there for a reason. Note that the 64-build already uses -mtune=generic, because it is free from the need to support Windows 9X. > 4. CPPFLAGS for XPM change follows the same pattern as cygwin. Both > cygwin and MSYS2 install the XPM library in an unusual place. Since > adding an include path for cygwin was already accepted, I did not see > any issue with adding a similar solution for MSYS2. IMO, it is a mistake in the Cygwin case as well. These issues should be resolved in the compiler installation, not in packages. If the user installs xpm (or any other library) she should either install its headers and library files in the standard places, or configure the compiler to look in the non-standard places (e.g., by setting C_INCLUDE_PATH in the environment). Otherwise, your build environment is not really 100% functional. I'd urge the Cygwin Emacs maintainers to revert that special case, but that's their call. For native Windows builds, I certainly object to introducing this deviation. > 5. I am sorry I was not aware of the ln flag issues. The -v was only > to see the result and it is completely unnecessary, while the -f was > needed just as it was used for "rm -f" in the original. The crash is > quite random, and currently I am unable to reproduce it. Yesterday it > was relatively easy to reproduce, but today it is not happening. > However, I remember that make stopped with something like: unable to > build emacs.exe on line 603 of src/Makefile with reason "rm: cannot > remove ‘bootstrap-emacs.exe’: Device or resource busy". The crash > happened even when running make without a j flag, that is non-parallel > build. > > The easy manual workaround is to just start make again, but then it is > hard to add emacs to any automated build system (for example as an > MSYS2 package). > > Given how random this crash is it is hard to justify any change to the > Makefile.in until I or someone else can find the root cause. I think the root cause is obvious: Windows won't let you delete the executable file of a running program. So small timing issues can open a small window of opportunity for this failure. How about adding a loop there that attempts to delete the file up to 5 times, say, each time sleeping for 1 second after a failure? If that works, it will always succeed on the 1st attempt on Posix hosts, so it is harmless there.