[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