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: Sat, 29 Nov 2014 12:32:41 +0200 Message-ID: <83oarql2k6.fsf@gnu.org> References: <87fvdfrl4p.fsf@telefonica.net> <83389d7t89.fsf@gnu.org> <87a93lrgct.fsf@wanadoo.es> <83mw7l6bjc.fsf@gnu.org> <87389dragi.fsf@wanadoo.es> <83egsx60um.fsf@gnu.org> <87y4r5pgae.fsf@wanadoo.es> <87ioi8pg84.fsf@wanadoo.es> <87egswpf9p.fsf@wanadoo.es> <87a93kp3lb.fsf@wanadoo.es> <9hwq6o11ud.fsf@fencepost.gnu.org> <87389cox4u.fsf@wanadoo.es> <87mw7gngw8.fsf@wanadoo.es> <87egsrnguj.fsf@wanadoo.es> <873896onl2.fsf@wanadoo.es> <87y4qyn840.fsf@wanadoo.es> <83zjbeoc40.fsf@gnu.org> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1417257211 24867 80.91.229.3 (29 Nov 2014 10:33:31 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 29 Nov 2014 10:33:31 +0000 (UTC) Cc: 19111@debbugs.gnu.org To: Dani Moncayo Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Sat Nov 29 11:33:24 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 1XufL8-0000LY-5y for geb-bug-gnu-emacs@m.gmane.org; Sat, 29 Nov 2014 11:33:22 +0100 Original-Received: from localhost ([::1]:47176 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XufL7-0004LJ-8b for geb-bug-gnu-emacs@m.gmane.org; Sat, 29 Nov 2014 05:33:21 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:55916) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XufKw-0004L2-J9 for bug-gnu-emacs@gnu.org; Sat, 29 Nov 2014 05:33:18 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XufKp-0002OT-1j for bug-gnu-emacs@gnu.org; Sat, 29 Nov 2014 05:33:10 -0500 Original-Received: from debbugs.gnu.org ([140.186.70.43]:51641) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XufKo-0002OP-Uc for bug-gnu-emacs@gnu.org; Sat, 29 Nov 2014 05:33:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1XufKo-0004Oi-Dl for bug-gnu-emacs@gnu.org; Sat, 29 Nov 2014 05:33: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: Sat, 29 Nov 2014 10:33: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.141725716516880 (code B ref 19111); Sat, 29 Nov 2014 10:33:02 +0000 Original-Received: (at 19111) by debbugs.gnu.org; 29 Nov 2014 10:32:45 +0000 Original-Received: from localhost ([127.0.0.1]:48854 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1XufKW-0004OC-Pd for submit@debbugs.gnu.org; Sat, 29 Nov 2014 05:32:45 -0500 Original-Received: from mtaout27.012.net.il ([80.179.55.183]:46772) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1XufKS-0004Ny-NS for 19111@debbugs.gnu.org; Sat, 29 Nov 2014 05:32:42 -0500 Original-Received: from conversion-daemon.mtaout27.012.net.il by mtaout27.012.net.il (HyperSendmail v2007.08) id <0NFS00H00PL80600@mtaout27.012.net.il> for 19111@debbugs.gnu.org; Sat, 29 Nov 2014 12:28:14 +0200 (IST) Original-Received: from HOME-C4E4A596F7 ([87.69.4.28]) by mtaout27.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NFS00AMLQF2CH80@mtaout27.012.net.il>; Sat, 29 Nov 2014 12:28:14 +0200 (IST) 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:96723 Archived-At: > Date: Sat, 29 Nov 2014 11:07:14 +0100 > From: Dani Moncayo > > I have to say that I still don't like the way of determining the host > platform on MinGW builds, because we are setting $host and $canonical > to a value (the compiler's target) that is not guaranteed to be > canonical (and in fact is not canonical in the cases I've tried, see > below). Why do you think it isn't canonical? For that matter, what is your definition of "canonical" in this context? > The following table shows the canonical host (as given by > 'build-aux/config.guess') and gcc target taken from the 5 different > build environments for MS-Windows I know of: > > # MSYS type $MSYSTEM canonical host gcc target > - ----------- -------- ----------------- ------------------ > 1 MSYS MINGW32 i686-pc-mingw32 mingw32 > 2 MSYS2-32bit MINGW32 i686-pc-mingw32 i686-w64-mingw32 > 3 MSYS2-32bit MINGW64 i686-pc-mingw64 x86_64-w64-mingw32 > 4 MSYS2-64bit MINGW32 x86_64-pc-mingw32 i686-w64-mingw32 > 5 MSYS2-64bit MINGW64 x86_64-pc-mingw64 x86_64-w64-mingw32 > ------------------------------------------------------------------ > > As you can see, our problem is only in the environments 3 and 4, where > the first part of the canonical triplet (CPU in CPU-VENDOR-OS) is not > what we want. Verification of the canonical configurations is the job of the config.sub script. In this case, it considers all the "gcc target" strings valid and outputs them intact, with a single exception: it replaces "mingw32" with "i386-pc-mingw32", which is correct because the mingw.org's development toolchain targets that host. I'm guessing you somehow think that the "pc" part must be there verbatim. But that is incorrect: it is just the default value of MANUFACTURER when the configuration type supplied "by other means" doesn't provide a MANUFACTURER. Since the *-w64-*-mingw32 configurations do provide MANUFACTURER, there's nothing wrong with them, and they cannot cause any harm, AFAIK. > But note that this problem is easily fixable: the CPU we want can be > deduced from the OS part of the triplet: > * mingw32 --> i686 > * mingw64 --> x86_64 I don't think we need that, since what we have now uses perfectly valid canonical configuration types. In any case, if you still are unconvinced, the way to fix this is to submit patches for config.sub, so that it does this mapping automatically. Its that script's job, not ours. Thanks.