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#19111: 25.0.50; 32 bits temacs.exe is linked with wrong image-base when built on 64 bit Windows host Date: Thu, 20 Nov 2014 18:05:26 +0200 Message-ID: <83389d7t89.fsf@gnu.org> References: <87fvdfrl4p.fsf@telefonica.net> <83k32q7wkl.fsf@gnu.org> <87bno2swxp.fsf@wanadoo.es> <83egsy7d2x.fsf@gnu.org> <87siheqzq9.fsf@wanadoo.es> 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 1416499585 22799 80.91.229.3 (20 Nov 2014 16:06:25 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 20 Nov 2014 16:06:25 +0000 (UTC) Cc: 19111@debbugs.gnu.org To: =?UTF-8?Q?=C3=93scar?= Fuentes Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Thu Nov 20 17:06:18 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 1XrUFN-0003EV-W8 for geb-bug-gnu-emacs@m.gmane.org; Thu, 20 Nov 2014 17:06:18 +0100 Original-Received: from localhost ([::1]:36043 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XrUFN-0002mR-HA for geb-bug-gnu-emacs@m.gmane.org; Thu, 20 Nov 2014 11:06:17 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:45387) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XrUFE-0002l6-HO for bug-gnu-emacs@gnu.org; Thu, 20 Nov 2014 11:06:13 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XrUF8-0000CZ-T7 for bug-gnu-emacs@gnu.org; Thu, 20 Nov 2014 11:06:08 -0500 Original-Received: from debbugs.gnu.org ([140.186.70.43]:42459) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XrUF8-0000CV-QZ for bug-gnu-emacs@gnu.org; Thu, 20 Nov 2014 11:06:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1XrUF8-00026w-Jn for bug-gnu-emacs@gnu.org; Thu, 20 Nov 2014 11:06:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 20 Nov 2014 16:06:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 19111 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 19111-submit@debbugs.gnu.org id=B19111.14164995328073 (code B ref 19111); Thu, 20 Nov 2014 16:06:02 +0000 Original-Received: (at 19111) by debbugs.gnu.org; 20 Nov 2014 16:05:32 +0000 Original-Received: from localhost ([127.0.0.1]:39672 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1XrUEd-000268-IR for submit@debbugs.gnu.org; Thu, 20 Nov 2014 11:05:31 -0500 Original-Received: from mtaout24.012.net.il ([80.179.55.180]:48392) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1XrUEa-00025x-56 for 19111@debbugs.gnu.org; Thu, 20 Nov 2014 11:05:29 -0500 Original-Received: from conversion-daemon.mtaout24.012.net.il by mtaout24.012.net.il (HyperSendmail v2007.08) id <0NFC00800HFSJT00@mtaout24.012.net.il> for 19111@debbugs.gnu.org; Thu, 20 Nov 2014 17:57:49 +0200 (IST) Original-Received: from HOME-C4E4A596F7 ([87.69.4.28]) by mtaout24.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NFC0043EHODD350@mtaout24.012.net.il>; Thu, 20 Nov 2014 17:57:49 +0200 (IST) In-reply-to: <87siheqzq9.fsf@wanadoo.es> 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:96322 > From: Óscar Fuentes > Cc: 19111@debbugs.gnu.org > Date: Thu, 20 Nov 2014 05:10:06 +0100 > > When we use the mingw toolset under MSYS{2} we are cross-compiling, as > far as autoconf is concerned. But truth is that Emacs' `configure.ac' > already special-cases MinGW by using $MSYSTEM and not requiring > --host/--build, to hide the cross-compilation and make user's life > simple. > > Such special handling of the MSYS/MinGW combo assumes that the target > architecture of the MinGW toolset being used is the same as the MSYS > architecture retrieved by `uname'. Yes, but it worked until now. It's a fragile situation, I agree, but the whole MSYS thing is fragile anyway. IMO, we are lucky that it works so well. > Once we have MSYS2 supporting both i686 and x86_64, and MinGW-w64 > also supporting both architectures, the assumption is broken. I > foresee similar problems when building for MINGW64 on a i686 MSYS2. > > > Patches for nt/INSTALL are welcome. > > Since we already special-case MinGW on the configure script, and fixing > the problem there only changes how the special case is implemented > without touching new areas, I'll very much prefer to apply the patch > shown on my previous message and keep the nice and simple "configure && > make" procedure working on all cases. OK, but at least let's keep the build/host/target triplet correct. It's not right for us to disregard it when it doesn't fit our needs, because the entire configure script is based on the notion that the triplet is the starting point on which all the rest is based. So, if we want to fix that, let's fix the triplet early on, to specify a i686 build, and let the rest of the script do its job as usual. Besides, I came to a conclusion that I don't understand how your suggestion will work anyway. AFAICT, you just replace tests based on one wrong string (x86_64-*-*) with another wrong string (MINGW64). Or are you saying that MSYS2 somehow magically does not give $MSYSTEM the value MINGW64 when you configure for a 32-bit build? If so, how does this magic work? Because if MSYS2 always sets MSYSTEM=MINGW64, then your suggestion isn't going to work, is it? More generally, how do you tell configure that you want a 32-bit build using MinGW64 toolchain? That requires some special compiler switches (like -m32 or some such), no?