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 <[email protected]> (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
--
Development mailing list
[email protected]
https://lists.qt-project.org/listinfo/development
