[Development] GCC 16 libstdc++ C++20 ABI break affects Qt C++17 builds, too

[Mathias Hasselmann]

Hi,


I completely understand how frustrating it is to deal with stdlib ABI 
breaks in Qt.

However, one of Qt’s great features is that you can download official Qt 
builds and run them on many different Linux distributions without any 
extra setup. It just works smoothly. No tweaks. No pain. It just works. 
This is a premium experience and a huge advantage of using Qt.

This is especially useful when you’re building a library and want to 
test it against different Qt versions. It’s even more helpful your CI 
system uses a different Linux distribution than your own computer.


So, if the extra effort to handle stdlib ABI breaks is manageable, I 
believe it’s worth it. The time you spend fixing these issues will save 
thousands of hours and energy and money for Qt users by letting them 
avoid building Qt from source.


Thank you for the great work,
Mathias


Am 20.01.26 um 20:52 schrieb Marc Mutz via Development:
> Hi,
>
> GCC 16 changed the numerical value of 
> std::partial_ordering::unordered. This is BiC, of course, but, as far 
> as we know, libstd++ only breaks the C++20 ABI, not the C++17 one.
>
> For better or worse, we have implemented Qt::partial_ordering as a 
> binary-compatible C++17 replacement for C++20 std::partial_ordering 
> (ditto the other ordering types, but, so far, no platform has broken 
> ABI for those, yet). Binary-compatible means that we hard-code our 
> numerical values to each stdlib's values. So there's no one 
> Qt::partial_ordering::unordered value, it differs per stdlib, and we 
> have tests that, in C++20 builds, make sure the two (Qt:: and std::) 
> are of the same size and numerical value.
>
> The idea was that the two are interchangeable both in BC and SC terms. 
> Because our C++17 types are made BC with the C++20 std types, a C++17 
> build of Qt now inherits the issue for GCC 15 → 16.
>
> We have two options, both of them are not optimal:
>
> We can continue to maintain BC with the std types and break BC for Qt 
> builds of GCC 15 and 16 or we maintain BC for Qt builds of GCC 15 and 
> 16 and break BC with the std types.
>
> We don't know which option is worse, so we'd like to get your 
> feedback. OTOH, users may have come to depend on the BC between the Qt 
> and std types and use them in their own ABIs. OTOH, users may expect 
> that a  C++17 build of Qt is BC between GCC 15 and 16 because 
> libstdc++ only broke BC for C++20 builds, not C++17 ones.
>
> We're in particular interested in how Linux distributions intend to 
> handle the issue. Are you shipping C++20 or C++17 builds of Qt? Or 
> separate ones? How do you handle the C++20 BiC in libstdc++ for GCC 16?
>
> Personally, I think fixing stdlib BiCs in Qt is a slippery slope. When 
> we accepted std types in the Qt ABI, we accepted that a stdlib ABI 
> break breaks Qt BC, too. The only reason we didn't see problems 
> earlier was that we're coming out of a 15-year period of stability 
> where no stdlib ABI was broken since C++11's container changes. So it 
> comes as a surprise now, even though we should have anticipated it all 
> the time.
>
> Whatddayathink?
>
> Thanks,
> Marc
>
> -- Marc Mutz <marc.mutz at qt.io> (he/his) Principal Software Engineer 
> The Qt Company Erich-Thilo-Str. 10 12489 Berlin, Germany www.qt.io 
> Geschäftsführer: Mika Pälsi, Juha Varelius, Jouni Lintunen Sitz der 
> Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 
> 144331 B
>
> Public
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20260120/4983719b/attachment.htm>