To everyone using Qt 4.6 from the Git repository: be aware that I introduced a binary-incompatible change. This change is there to stay.
No, we’re not breaking binary compatibility with Qt 4.5. This only affects previous Qt 4.6 versions.
Actually, this kind of change happens all the time. So why am I blogging about this specific change?
Well, the problem is that this change affects QHash, QMap and QVector. And those classes are inlined everywhere in Qt-using code. This means that, if you update Qt across that version, you must recompile all of the Qt-using code, from scratch (i.e., make clean). For KDE developers using trunk, that means recompiling all of KDE.
This change will be included in the upcoming Qt 4.6.0 Release Candidate.
Note: the change is in the 4.6 branch but hasn’t reached the 4.6-stable branch yet. That also means it’s not in kde-qt‘s 4.6-stable-patched branch yet. When you next update those stable branches, please remember to recompile everything.
PS: the stable branches aren’t updating not because of Qt not building. It is buiding. The reason why is because our Continuous Integration system experiencing some technical difficulties, like Windows running out of memory, the Symbian buildsystem failing for no apparent reason, the powerful 8-core Mac machines being able to run only one testcase at a time, etc.
No related posts.
10 comments
Thank you for the warning, but some more precise pieces of information would be welcome:
* What exactly makes this change binary-incompatible with previous Qt 4.6 prereleases?
* Why are binaries built against 4.5 not affected?
Am I missing the obvious?
Kevin, because the 4.5 binaries will all be compiled with the same inline version
This is a problem for 4.6 because the inlining of functions in some object files won’t match the behavior in other object files, hence the need for make clean.
After all that, you’re not going to tell us anything about what the change is, or why you made it? Now I’m curious… :^)
Would be interesting to have once a poll, about the importance of binary compatibility to Qt users (ie. from versions to versions, eg. 4.4, 4.5, 4.6,… ).
Maintaining BC with C++ libs really sucks and I guess that there are quite some (design) issues in Qt that won’t be fixed until Qt 5.
The Desktop App developers who will deploy their own Qt libraries (and suffer from constantly growing runtime sizes) propably won’t care. But with Qt becoming an integral part of Nokia’s mobile operating systems Symbian and Maemo this of a great importance. You cannot break all installed applications (or “Apps” as my mother calls them
just because of a firmware upgrade.
@ Jeremy Friesner: Just click on the second link in this article ( http://qt.gitorious.org/qt/qt/commit/e83bb2fdfc2dc899526c8157fd8b77a68cdde9da ) and you will know.
*ahem* as someone who made a feature request possibly leading to that change, i’d like to thanks Thiago! Right, there had to be one person happy about that change, for 1000 KDE developers who have to rebuild everything
When can we expect release candidate ? days ? weeks ? a month ?
Will it be compiled using gcc 4.x ? (not gcc 3.x as in the beta)
Can’t wait !
@divide: yes
For those interested: the BC break is the removal of the second overload of QHashData::detach_helper. I renamed that function to QHashData::detach_helper2. In retrospect, I didn’t have to, but now the deed is done.
It’s not a problem for code compiled against 4.5 because the overload didn’t exist. The problem only exists for code that was compiled while that overload existed.
Comments on this entry are closed.