Using different major Qt versions

koahnig

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.

fandras90

@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

kshegunov

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.

fandras90

@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)?

kshegunov

@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 and QObject and QMetaObject 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?

patrik08

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

fandras90

@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.

fandras90

@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.

kshegunov

@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 to QMetaObject. No compatible dynamic properties and QMetaType/QVariant serialization/deserialization and no (directly) compatible QDataStream 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.

JonB

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....

fandras90

@kshegunov
@JNBarchan
Thank you guys for all your input, you helped us a lot! :)