From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: Latest EMACS on BZR trunk does not compile with MinGW Date: Thu, 05 Jun 2014 20:52:57 +0300 Message-ID: <837g4v5jly.fsf@gnu.org> References: <80sinlu5kt.fsf@gmail.com> <538E2E90.4020706@cs.ucla.edu> <83mwdt8zkw.fsf@gnu.org> <83lhtd892x.fsf@gnu.org> <83tx807qdx.fsf@gnu.org> <83k38w7k7i.fsf@gnu.org> <83ha407j92.fsf@gnu.org> <834n006pcg.fsf@gnu.org> <87vbsg58ht.fsf@wanadoo.es> <83wqcv5s0x.fsf@gnu.org> <87r4335ny8.fsf@wanadoo.es> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: QUOTED-PRINTABLE X-Trace: ger.gmane.org 1401990815 15631 80.91.229.3 (5 Jun 2014 17:53:35 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 5 Jun 2014 17:53:35 +0000 (UTC) Cc: emacs-devel@gnu.org To: =?iso-8859-1?Q?=D3scar?= Fuentes Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Jun 05 19:53:28 2014 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 1Wsbqx-00077A-BA for ged-emacs-devel@m.gmane.org; Thu, 05 Jun 2014 19:53:27 +0200 Original-Received: from localhost ([::1]:43112 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Wsbqx-0007Zj-32 for ged-emacs-devel@m.gmane.org; Thu, 05 Jun 2014 13:53:27 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:48570) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Wsbqm-0007Xi-83 for emacs-devel@gnu.org; Thu, 05 Jun 2014 13:53:21 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Wsbqg-000538-LS for emacs-devel@gnu.org; Thu, 05 Jun 2014 13:53:16 -0400 Original-Received: from mtaout20.012.net.il ([80.179.55.166]:35038) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Wsbqg-00052j-E0 for emacs-devel@gnu.org; Thu, 05 Jun 2014 13:53:10 -0400 Original-Received: from conversion-daemon.a-mtaout20.012.net.il by a-mtaout20.012.net.il (HyperSendmail v2007.08) id <0N6P00M00IZXSJ00@a-mtaout20.012.net.il> for emacs-devel@gnu.org; Thu, 05 Jun 2014 20:53:08 +0300 (IDT) Original-Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout20.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0N6P00MJYJ0KCP60@a-mtaout20.012.net.il>; Thu, 05 Jun 2014 20:53:08 +0300 (IDT) In-reply-to: <87r4335ny8.fsf@wanadoo.es> X-012-Sender: halo1@inter.net.il X-detected-operating-system: by eggs.gnu.org: Solaris 10 X-Received-From: 80.179.55.166 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 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-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:172371 Archived-At: > From: =D3scar Fuentes > Date: Thu, 05 Jun 2014 18:19:11 +0200 >=20 > Eli Zaretskii writes: >=20 > >> Why not test if the preprocessor defines __MINGW32__? > > > > How will you call the compiler? Its exact name and directory isn= 't > > known until much later in the script. >=20 > The build failure came from the configure script deciding something > about dup2 based on MSYSTEM. No, dup2 is only a tip of an iceberg. When MSYSTEM is not defined, the configure script will not source nt/mingw-cfg.site, and quite a few other things will become broken/flawed in the resulting binary. nt/mingw-cfg.site is our way of augmenting the configure script in a way that keeps most of the gory details out of sight of most of the maintainers, who don't want to know too much about MinGW-specific quirks. > That sounds wrong to me: the characteristics of a function are > supposed to be decided based on specific tests. That means that whe= n > dup2 is probed by the configure script the test code should detect > that we are using the MS C runtime and return an specific code. Most of the configure-time tests indeed do that. But this particular test, and a few others, don't, because Emacs on Windows has special needs that are provided in Emacs's own sources; the configure script cannot possibly know about that, because it only probes system header= s and libraries. One such other example is the ACL-related primitives, which are coded entirely in w32.c; symlink support is yet another. I= n these cases, we force the configure script to make the correct decision by setting select shell variables to known values in mingw-cfg.site. > Is MSYSTEM relevant for anything that must be deciced before we can > invoke the compiler? See above. Better yet, just read configure.ac where it tests for tha= t variable, and then take it from there. It's really not so complicate= d. > > Perhaps we should only worry about detecting that MSYSTEM isn't s= et > > when it should be. For that, we can wait until the script figure= s out > > how to invoke the compiler, and _then_ see if the preprocessor de= fines > > __MINGW32__. If it does, but MSYSTEM is not set, we display an e= rror > > message and exit. I think this should be enough; valid MSYS > > installation should read /etc/profile and then they will have MSY= STEM > > defined. >=20 > Something like this would be good too, but please note that MSYSTEM= can > be defined with a wrong value. My build failure came from starting = MSYS2 > with the wrong script, the one that defines MSYSTEM to "MSYS". I know nothing about MSYS2; please consider providing the necessary details so some of them could be added to nt/INSTALL. I did add ther= e text that tells how to invoke the MSYS Bash to avoid this problem.