From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Achim Gratz Newsgroups: gmane.emacs.devel Subject: Re: ABI incompatibilities with MinGW GCC 4.7.0 Date: Sat, 09 Jun 2012 18:19:27 +0200 Message-ID: <87wr3go3u8.fsf@Rainer.invalid> References: <83ipf2ustm.fsf@gnu.org> <871ulopu3r.fsf@Rainer.invalid> <83k3zgtywl.fsf@gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Trace: dough.gmane.org 1339258902 8029 80.91.229.3 (9 Jun 2012 16:21:42 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Sat, 9 Jun 2012 16:21:42 +0000 (UTC) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Jun 09 18:21:41 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 1SdOPu-0004ED-8A for ged-emacs-devel@m.gmane.org; Sat, 09 Jun 2012 18:21:34 +0200 Original-Received: from localhost ([::1]:59437 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SdOPt-0006VU-Vk for ged-emacs-devel@m.gmane.org; Sat, 09 Jun 2012 12:21:33 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:51961) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SdOPd-000664-2z for emacs-devel@gnu.org; Sat, 09 Jun 2012 12:21:18 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1SdOPb-0003yz-1P for emacs-devel@gnu.org; Sat, 09 Jun 2012 12:21:16 -0400 Original-Received: from plane.gmane.org ([80.91.229.3]:54142) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SdOPa-0003ym-Qw for emacs-devel@gnu.org; Sat, 09 Jun 2012 12:21:14 -0400 Original-Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1SdOPV-0002r1-5Q for emacs-devel@gnu.org; Sat, 09 Jun 2012 18:21:09 +0200 Original-Received: from pd9eb42b5.dip.t-dialin.net ([217.235.66.181]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 09 Jun 2012 18:21:09 +0200 Original-Received: from Stromeko by pd9eb42b5.dip.t-dialin.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 09 Jun 2012 18:21:09 +0200 X-Injected-Via-Gmane: http://gmane.org/ Original-Lines: 58 Original-X-Complaints-To: usenet@dough.gmane.org X-Gmane-NNTP-Posting-Host: pd9eb42b5.dip.t-dialin.net User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.1 (gnu/linux) Cancel-Lock: sha1:NGzXenaK6igZKgkF0IaeGP6F1U4= X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 80.91.229.3 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:150863 Archived-At: Eli Zaretskii writes: > I very much hope you are right, but I'm not sure where your optimism > comes from. Simple. I know the default has been '-mno-ms-bitfields' and there are libraries that you can optionally compile with '-mms-bitfields' or that are even built that way by default (because they need to be linked to MS stuff more often than not). This particular trap is not something that has been created with gcc-4.7, it has existed for years. > 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. I'll grant you that, however you can go back and forth as often as you wish until all your libraries live at only one side of the chasm. > But what bothers me most is that no one said this is the only change > that affects C programs. It's said to be the only _binary_ incompatibility. Without further information to the contrary, I'll believe the gcc folks. > 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? As I said, you already have that problem today. You must make sure that _all_ your libraries are built one way or the other, but never mixed — or that the compiler generated bitfield layout is never exposed in a public interface, which is possible, but even harder to ascertain. If there's a bug here it is that there is a default for this switch at all, which only helps to forget that you have to make a choice and stick to it. > 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. Appreciated. I don't know if it's possible to look at a library and decide which way it's been compiled, but if there is, configure should be amended to check it for MinGW compiles and set the switch appropriately. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ SD adaptation for Waldorf Blofeld V1.15B11: http://Synth.Stromeko.net/Downloads.html#WaldorfSDada