[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: Achim Gratz
Subject: Re: ABI incompatibilities with MinGW GCC 4.7.0
Date: Sat, 09 Jun 2012 18:19:27 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.1 (gnu/linux)

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

+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

SD adaptation for Waldorf Blofeld V1.15B11:

reply via email to

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