unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: Eli Zaretskii <eliz@gnu.org>
To: Achim Gratz <Stromeko@nexgo.de>
Cc: emacs-devel@gnu.org
Subject: Re: ABI incompatibilities with MinGW GCC 4.7.0
Date: Sat, 09 Jun 2012 16:09:30 +0300	[thread overview]
Message-ID: <83k3zgtywl.fsf@gnu.org> (raw)
In-Reply-To: <871ulopu3r.fsf@Rainer.invalid>

> From: Achim Gratz <Stromeko@nexgo.de>
> 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.



  reply	other threads:[~2012-06-09 13:09 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-06-08  8:11 ABI incompatibilities with MinGW GCC 4.7.0 Eli Zaretskii
2012-06-08  9:42 ` joakim
2012-06-08 10:02   ` Eli Zaretskii
2012-06-09  3:10 ` Jason Rumney
2012-06-09  6:59   ` Eli Zaretskii
2012-06-09 12:06 ` Achim Gratz
2012-06-09 13:09   ` Eli Zaretskii [this message]
2012-06-09 14:44     ` Jason Rumney
2012-06-09 14:55       ` Eli Zaretskii
2012-06-09 16:19     ` Achim Gratz
2012-06-09 18:13       ` Eli Zaretskii
2012-06-09 18:55         ` Achim Gratz

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=83k3zgtywl.fsf@gnu.org \
    --to=eliz@gnu.org \
    --cc=Stromeko@nexgo.de \
    --cc=emacs-devel@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).