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: ABI incompatibilities with MinGW GCC 4.7.0 Date: Sat, 09 Jun 2012 16:09:30 +0300 Message-ID: <83k3zgtywl.fsf@gnu.org> References: <83ipf2ustm.fsf@gnu.org> <871ulopu3r.fsf@Rainer.invalid> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: dough.gmane.org 1339247467 26926 80.91.229.3 (9 Jun 2012 13:11:07 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Sat, 9 Jun 2012 13:11:07 +0000 (UTC) Cc: emacs-devel@gnu.org To: Achim Gratz Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Jun 09 15:11:06 2012 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 1SdLRS-0001Yd-CL for ged-emacs-devel@m.gmane.org; Sat, 09 Jun 2012 15:10:58 +0200 Original-Received: from localhost ([::1]:36816 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SdLRS-0001tf-4u for ged-emacs-devel@m.gmane.org; Sat, 09 Jun 2012 09:10:58 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:58639) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SdLRO-0001tR-GT for emacs-devel@gnu.org; Sat, 09 Jun 2012 09:10:55 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1SdLRK-0007VQ-8O for emacs-devel@gnu.org; Sat, 09 Jun 2012 09:10:54 -0400 Original-Received: from mtaout23.012.net.il ([80.179.55.175]:56423) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SdLRJ-0007Um-W6 for emacs-devel@gnu.org; Sat, 09 Jun 2012 09:10:50 -0400 Original-Received: from conversion-daemon.a-mtaout23.012.net.il by a-mtaout23.012.net.il (HyperSendmail v2007.08) id <0M5C00F00PLA8400@a-mtaout23.012.net.il> for emacs-devel@gnu.org; Sat, 09 Jun 2012 16:09:27 +0300 (IDT) Original-Received: from HOME-C4E4A596F7 ([87.69.210.75]) by a-mtaout23.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0M5C00FEGPVQ7030@a-mtaout23.012.net.il>; Sat, 09 Jun 2012 16:09:27 +0300 (IDT) In-reply-to: <871ulopu3r.fsf@Rainer.invalid> X-012-Sender: halo1@inter.net.il X-detected-operating-system: by eggs.gnu.org: Solaris 10 (beta) X-Received-From: 80.179.55.175 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:150856 Archived-At: > From: Achim Gratz > Date: Sat, 09 Jun 2012 14:06:48 +0200 > > Eli Zaretskii writes: > > See http://sourceforge.net/mailarchive/message.php?msg_id=29376223 and > > the following discussion (which is still unfolding) for the details. > > The first of these is a red herring. I very much hope you are right, but I'm not sure where your optimism comes from. > You always needed to know whether all libraries you link to were > produced with '-mms-bitfields' or '-mno-ms-bitfields' anyway ever > since that option was introduced. So the default changes with > 4.7.0, but you can just as easily chose the former default. When one builds a library, one usually follows the build instructions (unless they are the maintainers, which is rarely the case for a Windows build). These instructions mostly boil down to ./configure && make && make check && make install or something similar. When a library is built this way, the GCC options used are the default ones, plus whatever the package-specific Makefile's set. You can guess what would be the probability of having '-mms-bitfields' among those switches; I can _tell_ you that I never ever saw them when I built libraries (some of which are recommended for optional Emacs features). So in practice, I submit that most, if not all, of the precompiled libraries out there were build with the equivalent of '-mno-ms-bitfields', and therefore the new default is actually, not just theoretically, different. But what bothers me most is that no one said this is the only change that affects C programs. > > (Actually, you cannot safely use the MinGW GCC 4.7.0 for building > > Emacs on Windows at all for now, because (a) there's no MinGW runtime > > available that is compatible with the new ABI, and (b) you must link > > with libxpm.dll, which was compiled by an older GCC.) > > I still think that simply adding '-mno-ms-bitfields' to the build is all > you need for Emacs If we know the libraries out there are not built with GCC 4.7.x, then this is indeed the way to go. But what about people who like to build all their libraries themselves? if they use GCC 4.7 to build their libraries, and don't make a point of using '-mno-ms-bitfields' when they do, we cannot let them build Emacs with '-mno-ms-bitfields', can we? And then there's the issue of other ABI changes, if there are any. That is the really disturbing part, because the bitfields issue rarely if at all affects real-life code. > There is a disturbing lack of consideration for backwards > compatibility and I would have expected that the ABI version is > bumped (so one could specify the old default with, say, -mabi=...). > If there's really no way to get the old default back without > qualifying all functions in the source, I'd consider that a defect > that needs to be fixed for 4.7.1. I agree. But this list is not concerned with maintaining GCC, it uses GCC to build Emacs. I posted the info here to try to proactively avoid subtle problems this ABI change could produce, if people haste to upgrade.