[Development] Binary incompatible change in QtConcurrent - was - Re: Qt 5.15.6 Opensource released
Albert Astals Cid
aacid at kde.org
Thu Sep 8 23:06:24 CEST 2022
El dimecres, 7 de setembre de 2022, a les 14:16:23 (CEST), Tarja Sundqvist va escriure:
> Hi all,
>
>
>
> we have released Qt 5.15.6 opensource today:
>
>
>
> * release note:
> https://code.qt.io/cgit/qt/qtreleasenotes.git/about/qt/5.15.6/release-note.
> md * source packages in download.qt.io:
> * https://download.qt.io/official_releases/qt/5.15/5.15.6/
> *
> https://download.qt.io/official_releases/QtForPython/pyside2/PySide2-5.15.6
> -src/ * Git: clone the release with the tag v5.15.6-lts-lgpl
>
This Qt release comes with a binary incompatible change in this commit
https://code.qt.io/cgit/qt/qtbase.git/commit/src/concurrent?h=v5.15.6-lts-lgpl&id=4d6752e8d2ed9d303befe7adf7f6e4b6ba16bbb9
Example of that symbol being used in the wild
$ nm -D -C /usr/lib/qt/plugins/ktexteditor/kateprojectplugin.so | grep -i startBlocking
U QtConcurrent::ThreadEngineBase::startBlocking()@Qt_5
This is due to the code calling QtConcurrent::blockingMap and blockingMap using startBlocking from a template.
This binary incompatible change also existed in the Qt 6.3 release in the shape of commit 1bf75f2a661c05c7f1126187310d7df3f9704af5
I guess there's no one using Qt 6.x that cares about Binary Compatibility so it wasn't found.
Should we restore those symbols or just accept that Qt 6 broke BC a year ago and no one realized so why bring the symbols back?
Cheers,
Albert
>
> Best regards
>
> Tarja Sundqvist
>
> Release manager
More information about the Development
mailing list