[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: ABI incompatibilities with MinGW GCC 4.7.0

From: Eli Zaretskii
Subject: Re: ABI incompatibilities with MinGW GCC 4.7.0
Date: Sat, 09 Jun 2012 16:09:30 +0300

> From: Achim Gratz <address@hidden>
> 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

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 via email to

[Prev in Thread] Current Thread [Next in Thread]