[Interest] Binary Compatibility breakage in Qt Multimedia 6.7.0

[Volker Hilsheimer]

Hi,

I managed to break binary compatibility in the Qt Multimedia module of the 6.7.0 release :(

https://bugreports.qt.io/browse/QTBUG-123997

TL;DR: Qt 6.7.1 will be binary compatible with older Qt 6 versions again, but you will have to rebuild code using QAudioSink or QAudioSource when moving from earlier releases to Qt 6.7.0, and also rebuild when moving from Qt 6.7.0 to Qt 6.7.1. Qt 6.7.1 is as of now scheduled for 2nd half May [1], but we will reevaluate that given this breakage, depending on what other feedback we get to the Qt 6.7.0 release.

[1] https://wiki.qt.io/Qt_6.7_Release

The fix is in https://codereview.qt-project.org/c/qt/qtmultimedia/+/553006 (merged into dev at time of writing, and on it’s way into the Qt 6.7 branch).

Some more details:

Qt namespaces are named “QtSomething”, and the QAudio namespace in Qt Multimedia is named inconsistently - `Q` instead of `Qt`. This became more obvious when we introduced a namespace QtVideo for video related stuff, so we wanted to fix that. This resulted in a change that unfortunately broke binary compatibility by changing the stateChanged() signal’s signature in both QAudioSink and QAudioSource. Qt 6.6 exports this symbol as `stateChanged(QAudio::State)`, while in Qt 6.7.0 it’s exported only as `stateChanged(QtAudio::State)`.

Unfortunately, adding the signal with the old signature back turned out to be impossible. We’d have to have two signals, `QAudioSource::stateChanged(QtAudio::State)` and `QAudioSource::stateChanged(QAudio::State)` exported as symbols. But we cannot have both signals in the API, as otherwise `&QAudioSource::stateChanged` would be ambiguous and break compilation. And if we export the old signal function as a symbol that is not exposed to the public API, then already compiled code making connections to the signal member function (using PMF syntax) will fail - they would still be different functions, after all.

Apologies for the inconvenience this causes. We are following up to make sure that the tests that we run regularly to verify binary compatibility catch this next time.

Volker