Solved Using different major Qt versions
-
You can (re)compile against different major Qt versions (e.g. Qt4 and Qt5), but you may have to use #if to separate diffent sections in your code.
However, using Qt4 and Qt5 parallel in the very same application does not sound like a good idea at all. You might be able to create a small "hello world" in doing it, but I'm even doubting this.
My recommendation is to migrate your Qt4 completely to Qt5. I have done in the past and it was minor issue adapting some includes other other parts.
-
Hey @koahnig ,
Thanks for your quick response! :) We would definitely migrate to Qt5 if it would be an option but unfortunately it is not, at least not all parts of the app.
We have already managed to migrate some parts though, so it indeed works, we use different versions in the app, yet the compilation units are built against one single version without mixing. Meaning that we have some dlls that are created using Qt4 and some others that depend on Qt5. Could you please point out some reasons why using them parallel does not sound like a good idea? We are getting more and more confused about it...:)
Thank you! -
I am being merely a user without enough detailed knowledge on dll interfaces.
As long as you are having only C/C++ parameters while calling routines in those different dlls you might have a chance. However, as soon as you have Qt objects on calling lists, I doubt that this can work.
I will bring up the topic to the attention of other mods with possible more experience.
-
@koahnig
Yes, we were thinking about the same "might" but need to turn it into something concrete :)
Thanks for spreading our issue, hope we will find our answer -
Just forget it. Qt has internal statics that you'll get different copies of for each of the Qt versions. This means separate event loops, separate widget window manager integrations and so on. You are not going to able to make this work, not in my lifetime.
-
@kshegunov
That's one step forward, thanks a lot for your response!
However this raises more questions to me. Can I find a document related to these statics somewhere? I mean, we have separable modules, we require one QMainWindow class with its event loop that would be in Qt5, and we pass some QStrings and Qt containers inside the Qt4 modules, while the modules themselves have Qt-independent interfaces for interactions between each other.
The simplified case is the following:
We have a dll X which is built against Qt4, and we have pure C++ interfaces to export in the dll.
On the other hand, we have another dll Y which would use X and Qt5.
As I understand binary incompatibility, the Qt dlls from the two different versions would not be able to distract each other, would they? So - as in my initial question - it is clearly understandable why we cannot get a Qt4 slot, with queued connection type, invoked with only running a Qt5 event loop.
So can we handle different Qt versions as they were completely different libs (with no connections to each other even in the source code)? -
@fandras90 said in Using different major Qt versions:
Can I find a document related to these statics somewhere?
No. These are internal to Qt, they are inside the so/dll files and are not exported as an interface; you have no access to them whatsoever.
I mean, we have separable modules, we require one QMainWindow class with its event loop that would be in Qt5, and we pass some QStrings and Qt containers inside the Qt4 modules, while the modules themselves have Qt-independent interfaces for interactions between each other.
Not according to your signal-slot example in the original post. It is theoretically possible to link and work it like this only if there is no Qt shared code between the two libraries. This includes even trivial things like
QString
taken from one of your libraries that goes as a function argument to the other library and absolutely no GUI andQObject
andQMetaObject
stuff dependence that goes between the two. Basically you can make it work if one of the libraries uses only reentrant classes and functions internally, although I continue to see no point of doing it like this.As I understand binary incompatibility, the Qt dlls from the two different versions would not be able to distract each other, would they?
Binary compatibility has no bearing here. Even if a given class is binary compatible, it carries with it a private part. Take a
QString
from one library and pass it to another (even if they're binary compatible) and you'd see all kinds of weird crashes if the private object has changed.So can we handle different Qt versions as they were completely different libs (with no connections to each other even in the source code)?
In theory if the Qt calls and functionalities are completely segregated between the two. Think about it as linking two completely different frameworks.
What you're trying to create is a centaur - half a man, half a horse - completely incompatible creatures melded into one. Ever seen one of those in real life?
-
Hi..
My last action i have successful porting a project from qt4 to qt5.9, my basic is to make a bridge from all function wo is chance
all file that compiler not accept have this code:#ifndef READONFIGOK #include <QtGlobal> #if QT_VERSION < QT_VERSION_CHECK(5, 0, 0) #include "qt4config.h" #else #include "qt5config.h" #endif #endif
on qt5config.h
#ifndef CONFIGQT5_RUN #define CONFIGQT5_RUN #include <QtGlobal> #if (QT_VERSION >= QT_VERSION_CHECK(5, 0, 0)) #include <QMainWindow> #include <QApplication> #include <QtGui> #include <QFontDatabase> #include <QtCore/QCoreApplication> //// & other thing only qt5 #define Q_WS_MAC Q_OS_MAC #define Q_WS_WIN Q_OS_WIN #define Q_WS_X11 Q_OS_X11 #define Q_WS_LINUX Q_OS_LINUX //// swap functions namespace Qt { inline static QString stringHtmlEscapedqt5( QString x) { return QString(x).toHtmlEscaped(); } #define escape stringHtmlEscapedqt5 } #define toAscii toLatin1 #define fromAscii fromLatin1 /// debug action #if 0 //// 1 or 0 #define SCDEBUG qDebug #define STAGE 1 #define _debuglogfile_ \ QString("/Volumes/dati/mim_log.txt") #else #define SCDEBUG \ if (0) \ qDebug #define STAGE 0 #define _debuglogfile_ QString("") #endif #endif /// debug visual #define READONFIGOK /// debug action #endif
at end i can build all in qt4.8 & on qt5.9
only network module have a big chance ...
other info on: https://wiki.qt.io/Transition_from_Qt_4.x_to_Qt5 -
@kshegunov said in Using different major Qt versions:
In theory if the Qt calls and functionalities are completely segregated between the two. Think about it as linking two completely different frameworks.
That's the point, so despite it seems pointless, and looks like a centaur it can exist and it would work seamlessly, right? Afterwards, it is "just" an architectural problem how to separate the "completely different frameworks" - as we think of them this way in our case. So no shared code, no Qt arguments, strict line between the two.
Thank you so much for spending your precious time on my question, I really appreciate it. -
@patrik08
Thanks for your reply! The issue is not related to the compile time separation of the two versions, but rather a design time decision about which one to use and how to use them in different dlls, and make them work together in one single application.
Anyway I really appreciate your code example as it points out the differences that should be considered during a migration. -
@fandras90 said in Using different major Qt versions:
So no shared code, no Qt arguments, strict line between the two.
This includes, as I wrote, between the two libraries: no GUI access, no
QApplication
/QCoreApplication
, no signal-slot connections or anything remotely related toQMetaObject
. No compatible dynamic properties andQMetaType
/QVariant
serialization/deserialization and no (directly) compatibleQDataStream
writes/reads. In the end what is left is basically the containers, XML classes and strings/byte arrays/regular expressions. In my mind it would take much less time to port your code to Qt5 than to troubleshoot all the possible problems which can jump up by doing those shenanigans. -
Totally agree with @kshegunov. Unless your
Qt5
&Qt4
parts are totally and utterly separate you will have problems, and it may not be obvious at runtime where a fault lies.... -
@kshegunov
@JNBarchan
Thank you guys for all your input, you helped us a lot! :)