[Interest] [Mingw-w64-public] Compiling Qt (4 or 5) with "-std=c++11"

K. Frank kfrank29.c at gmail.com
Fri Mar 22 04:26:38 CET 2013


Hello Thiago!

Thank you for the detailed explanation.

On Thu, Mar 21, 2013 at 9:44 PM, Thiago Macieira
<thiago.macieira at intel.com> wrote:
> On quinta-feira, 21 de março de 2013 17.30.12, K. Frank wrote:
>> Hi Thiago!
>>  ...
>> >> As I understand it, using "-std=c++11" causes abi breakage, so to do
>> >> this, I will have to recompile the various libraries I use.
>> >
>> > Not with Qt. Qt has the very same ABI, whether you compile it with C++11
>> > or
>> > C++98.
>>
>> I guess I should take your word for it.  But I'm a little confused, so let
>> me ask for some clarification.  How does Qt control the abi produced by the
>> compiler?  I was under the distinct impression that "-std=???11" caused
>> significant abi breakage, that this was recognized as an issue, but, I
>> guess, that the gcc folks felt that it was worth it for some reason.
>>
>> How could Qt manage to dodge that bullet?  Or am I misunderstanding
>> the issue?
>
> You're misunderstanding the issue.
>
> The compiler ABI is exactly the same. There has been no change to the calling
> convention or the naming of external symbols ("mangling") for existing
> functions. The mangling has new codes so it can support the new C++11 types
> and features (Ds and Di for char16_t and char32_t and support for variadic
> template packs, for example).
>
> However, Qt is quite clever about the use of such features: those types and
> features only appear in inline functions. Therefore, the external symbols
> exported by Qt are the same, no matter how you compile the Qt libraries.

Thanks.  That's very good to know.

> That's not actually the case if you use Visual Studio, but there the situation
> is completely different. For starters, you can't choose to enable C++11: it's
> always enabled. And second, Microsoft hasn't heard yet about C++ binary
> compatibility. If you upgrade your compiler, you must recompile everything, so
> it doesn't matter which features we use.

Well, for what it's worth, I'm only using mingw / mingw-w64 at the moment.

> You may be actually thinking of some reports that the Standard C++ Library
> that comes with GCC broke compatibility. I've heard the same, and I've also
> heard that it was reverted, or misunderstood. So in the end, I simply don't
> know what the situation is. But it's irrelevant for Qt, since we do not use
> the Standard Library in our public, non-inline functions.

Thank you for explaining that.  I think it was, indeed, the standard
library issue I was remembering.  It probably should have occurred
to me that Qt, being a framework, already has its own versions of
most of the standard library facilities.

> If you're interested in a binary compatibility topic that might affect you --
> and since you so kindly brought the mingw community in -- be careful about the
> C++ exception model from your mingw compiler. They are binary-incompatible
> with one another, if you use exceptions. The MinGW community needs to choose
> one model, once and for all, deprecate all others, period. Just choose one,
> any one, provided it's not SJLJ. If your compiler uses SJLJ, run from it and
> avoid it like the plague. If that's the only option available, choose another
> compiler.

Yes, another compatibility issue.  I've been using the dwarf2 version.
(But there are sjlj advocates out there.)

> Thiago Macieira - thiago.macieira (AT) intel.com
>   Software Architect - Intel Open Source Technology Center

Thanks for taking the time to clear these things up.


K. Frank



More information about the Interest mailing list