[Interest] Porting custom QML plugin to the Qt6
Lately, mostly for fame and glory, I decided to port some of my stuff from Qt5 to Qt6.
Most of it went ok'ish - after some CMakeLists.txt hacking and 'modernizing' the code I
was able to compile two of my dynamic libraries under Qt6.
Problems started with my custom QML plugin. Here after compiling and importing my module
in my example app I got:
"qrc:/src/QML/MainWindow.qml:5:1: module "IzLibrary" plugin "IzLibraryPlugin" not
found"
Well oopsie doopsie, some more work is needed. After quick look at:
https://doc.qt.io/qt-6/qtqml-modules-cppplugins.html
I spotted, I believe, the most important changes. QQmlExtensionPlugin being changed to
QmlEngineExtensionPlugin, QML_ELEMENT added in Qt 5.15.X and removal of
QQmlExtensionPlugin::registerTypes.
Then I noticed stuff about QML_IMPORT_NAME, QML_IMPORT_MAJOR_VERSION and 'CONFIG +=
qmltypes' that are supposed to be added to the .pro project files. And, although, docs are
silent about CMake, there is handy example located at:
https://code.qt.io/cgit/qt/qtdeclarative.git/tree/examples/qml/qmlextensionplugins/CMakeLists.txt?h=6.0
I added to my CMakeLists.txt:
set_target_properties(
IzLibraryPlugin
PROPERTIES
QT_QML_MODULE_VERSION 1.0
QT_QML_MODULE_URI IzLibrary
)
omitting, for the moment, the "QT_QMLTYPES_FILENAME imports/TimeExample/plugins.qmltypes"
as I was typically generating .qmltypes manually using the supplied qmlplugindump and some
associated CMake hackery.
I also added the:
qt6_qml_type_registration(IzLibraryPlugin)
And this is when first build error occurred. qt6_qml_type_registration seems to be trying
to automate some of the QML type registration machinery and generates the
"izlibraryplugin_qmltyperegistrations.cpp" file. In my case it looks like this:
#include
#include
#include
#include
#include
void qml_register_types_IzLibrary()
{
qmlRegisterTypesAndRevisions("IzLibrary", 1);
qmlRegisterTypesAndRevisions("IzLibrary", 1);
qmlRegisterTypesAndRevisions("IzLibrary", 1);
QMetaType::fromType().id();
QMetaType::fromType().id();
qmlRegisterModule("IzLibrary", 1, 0);
}
static const QQmlModuleRegistration registration("IzLibrary",
qml_register_types_IzLibrary);
But! My includes are not available under but rather under
"IzLibrary/SomeBeautifulHeader.h" as denoted by my target_include_directories:
# include directories for target
target_include_directories(
IzLibraryPlugin
PUBLIC
$
$
PRIVATE
${CMAKE_CURRENT_SOURCE_DIR}/private
)
So, my questions (for now :P) are:
Is this the intended behavior or have I fubared something and not added "something,
somewhere" in my CMakeLists.txt?
Is there a documentation for the qt6_* cmake functions?
Is the stuff "qt6_add_qml_module" important or can I skip it?
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest
Re: [Interest] Qt Creator licensing for companies with Qt Commercial developers
Or is this only in case of ‘mixed env’ users – having both commercial and non-commercial licenses? From: Jakub NarolewskiSent: 27 March 2020 14:27To: Jérôme Godbout; Tuukka Turunen; Vyacheslav Lanovets; interest@qt-project.orgSubject: RE: Re: [Interest] Qt Creator licensing for companies with Qt Commercial developers Maybe I misunderstood something so just correct me.If I use – commercially – QtCreator as my daily IDE without using Qt library or attached modules, I still need to pay for full Qt license? Cheers,Jakub Narolewski From: Jérôme GodboutSent: 27 March 2020 14:22To: Tuukka Turunen; Vyacheslav Lanovets; interest@qt-project.orgSubject: Re: [Interest] Qt Creator licensing for companies with Qt Commercial developers Hi, is it just me or this is heading into the wrong way, or at least into the opposite direction of the market. Most IDE are now free, even the embedded world start giving IDE away:xCode is freevs code is freeAtollic is freeSTM32 TrueStudio is free.. People are leaving pricy IDE behind, Keil anyone? less and less used. Starting to pay for an IDE like QtCreator, seem like you will only get less users toward Qt or people might be temped more and more to use VisualStudio as an IDE of choice. This is my personnal point of view on the subject,My 2 cents, -Original Message-From: Interest On Behalf Of Tuukka TurunenSent: March 27, 2020 8:56 AMTo: Vyacheslav Lanovets ; interest@qt-project.orgSubject: Re: [Interest] Qt Creator licensing for companies with Qt Commercial developers Hi, Correct. All users need to have commercial license. It is not allowed for part of the team to use commercial and part use open-source. Even though Qt Creator is great, it can feel odd to pay for full Qt license and only use the Creator IDE. We have been thinking about selling Qt Creator separately, but so far no decisions made on this. Yours, Tuukka On 25.3.2020, 21.09, "Interest on behalf of Vyacheslav Lanovets" wrote: Hi, Situation. A company has a few developers with Qt Commercial subscription who write applications in Qt for iOS. There are many other developers, who work on other projects and don't use Qt libraries. They talk to each other and sometimes even work on the same code. Is it still possible for the developers who don't use Qt libraries in any way, use Qt Creator IDE for editing and debugging? To be on the safe side, company plans to prohibit usage of Qt Creator IDE for all employees. I reckon this is a popular solution. If I understand correctly, Qt even sells a special option to ban all company IP addresses for open-source installer. But is it really so? Regards, Vyacheslav ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest ___Interest mailing listInterest@qt-project.orghttps://lists.qt-project.org/listinfo/interest___Interest mailing listInterest@qt-project.orghttps://lists.qt-project.org/listinfo/interest ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] Qt Creator licensing for companies with Qt Commercial developers
Maybe I misunderstood something so just correct me.If I use – commercially – QtCreator as my daily IDE without using Qt library or attached modules, I still need to pay for full Qt license? Cheers,Jakub Narolewski From: Jérôme GodboutSent: 27 March 2020 14:22To: Tuukka Turunen; Vyacheslav Lanovets; interest@qt-project.orgSubject: Re: [Interest] Qt Creator licensing for companies with Qt Commercial developers Hi, is it just me or this is heading into the wrong way, or at least into the opposite direction of the market. Most IDE are now free, even the embedded world start giving IDE away: xCode is freevs code is freeAtollic is freeSTM32 TrueStudio is free.. People are leaving pricy IDE behind, Keil anyone? less and less used. Starting to pay for an IDE like QtCreator, seem like you will only get less users toward Qt or people might be temped more and more to use VisualStudio as an IDE of choice. This is my personnal point of view on the subject,My 2 cents, -Original Message-From: Interest On Behalf Of Tuukka TurunenSent: March 27, 2020 8:56 AMTo: Vyacheslav Lanovets ; interest@qt-project.orgSubject: Re: [Interest] Qt Creator licensing for companies with Qt Commercial developers Hi, Correct. All users need to have commercial license. It is not allowed for part of the team to use commercial and part use open-source. Even though Qt Creator is great, it can feel odd to pay for full Qt license and only use the Creator IDE. We have been thinking about selling Qt Creator separately, but so far no decisions made on this. Yours, Tuukka On 25.3.2020, 21.09, "Interest on behalf of Vyacheslav Lanovets" wrote: Hi, Situation. A company has a few developers with Qt Commercial subscription who write applications in Qt for iOS. There are many other developers, who work on other projects and don't use Qt libraries. They talk to each other and sometimes even work on the same code. Is it still possible for the developers who don't use Qt libraries in any way, use Qt Creator IDE for editing and debugging? To be on the safe side, company plans to prohibit usage of Qt Creator IDE for all employees. I reckon this is a popular solution. If I understand correctly, Qt even sells a special option to ban all company IP addresses for open-source installer. But is it really so? Regards, Vyacheslav ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest ___Interest mailing listInterest@qt-project.orghttps://lists.qt-project.org/listinfo/interest___Interest mailing listInterest@qt-project.orghttps://lists.qt-project.org/listinfo/interest ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
[Interest] QAbstractEventDispatcher - registerSocketNotifier(), unregisterSocketNotifier()
I have this pet project of mine in which I'm testing the possibility of integrating libuv's event loop cleanly with Qt.After some research I come to conclusion that custom class based on QAbstractEventDispatcher will be perfect for this. Some prototyping later and - give or take few bugs - it seems to be somewhat working :] Given the lack of written examples on how things work on this level I'm not quite sure about one thing.Both methods - registerSocketNotifier() and unregisterSocketNotifier() - get called very frequently on the same QSocketNotifier, with identical QSocketNotifier::Type.Example debug output looks like this: [debug ] 18:33:48.013 LibUvEventDispatcher::registerSocketNotifier() QSocketNotifier(0x1cb64fde5a0) [debug ] 18:33:48.024 LibUvEventDispatcher::unregisterSocketNotifier() QSocketNotifier(0x1cb64fde5a0) [debug ] 18:33:48.061 LibUvEventDispatcher::registerSocketNotifier() QSocketNotifier(0x1cb64fde5a0) [debug ] 18:33:48.072 LibUvEventDispatcher::unregisterSocketNotifier() QSocketNotifier(0x1cb64fde5a0) [debug ] 18:33:48.110 LibUvEventDispatcher::registerSocketNotifier() QSocketNotifier(0x1cb64fde5a0) [debug ] 18:33:48.121 LibUvEventDispatcher::unregisterSocketNotifier() QSocketNotifier(0x1cb64fde5a0) [debug ] 18:33:48.157 LibUvEventDispatcher::registerSocketNotifier() QSocketNotifier(0x1cb64fde5a0) [debug ] 18:33:48.168 LibUvEventDispatcher::unregisterSocketNotifier() QSocketNotifier(0x1cb64fde5a0) [debug ] 18:33:48.205 LibUvEventDispatcher::registerSocketNotifier() QSocketNotifier(0x1cb64fde5a0) [debug ] 18:33:48.216 LibUvEventDispatcher::unregisterSocketNotifier() QSocketNotifier(0x1cb64fde5a0) [debug ] 18:33:48.253 LibUvEventDispatcher::registerSocketNotifier() QSocketNotifier(0x1cb64fde5a0) [debug ] 18:33:48.265 LibUvEventDispatcher::unregisterSocketNotifier() QSocketNotifier(0x1cb64fde5a0) [debug ] 18:33:48.301 LibUvEventDispatcher::registerSocketNotifier() QSocketNotifier(0x1cb64fde5a0) [debug ] 18:33:48.311 LibUvEventDispatcher::unregisterSocketNotifier() QSocketNotifier(0x1cb64fde5a0) [debug ] 18:33:48.349 LibUvEventDispatcher::registerSocketNotifier() QSocketNotifier(0x1cb64fde5a0) [debug ] 18:33:48.360 LibUvEventDispatcher::unregisterSocketNotifier() QSocketNotifier(0x1cb64fde5a0) [debug ] 18:33:48.397 LibUvEventDispatcher::registerSocketNotifier() QSocketNotifier(0x1cb64fde5a0) [debug ] 18:33:48.407 LibUvEventDispatcher::unregisterSocketNotifier() QSocketNotifier(0x1cb64fde5a0) [debug ] 18:33:48.445 LibUvEventDispatcher::registerSocketNotifier() QSocketNotifier(0x1cb64fde5a0) [debug ] 18:33:48.456 LibUvEventDispatcher::unregisterSocketNotifier() QSocketNotifier(0x1cb64fde5a0) [debug ] 18:33:48.494 LibUvEventDispatcher::registerSocketNotifier() QSocketNotifier(0x1cb64fde5a0) [debug ] 18:33:48.504 LibUvEventDispatcher::unregisterSocketNotifier() QSocketNotifier(0x1cb64fde5a0) [debug ] 18:33:48.542 LibUvEventDispatcher::registerSocketNotifier() QSocketNotifier(0x1cb64fde5a0) [debug ] 18:33:48.553 LibUvEventDispatcher::unregisterSocketNotifier() QSocketNotifier(0x1cb64fde5a0) [debug ] 18:33:48.590 LibUvEventDispatcher::registerSocketNotifier() QSocketNotifier(0x1cb64fde5a0) [debug ] 18:33:48.601 LibUvEventDispatcher::unregisterSocketNotifier() QSocketNotifier(0x1cb64fde5a0) [debug ] 18:33:48.638 LibUvEventDispatcher::registerSocketNotifier() QSocketNotifier(0x1cb64fde5a0) [debug ] 18:33:48.649 LibUvEventDispatcher::unregisterSocketNotifier() QSocketNotifier(0x1cb64fde5a0) [debug ] 18:33:48.686 LibUvEventDispatcher::registerSocketNotifier() QSocketNotifier(0x1cb64fde5a0) [debug ] 18:33:48.697 LibUvEventDispatcher::unregisterSocketNotifier() QSocketNotifier(0x1cb64fde5a0) [debug ] 18:33:48.734 LibUvEventDispatcher::registerSocketNotifier() QSocketNotifier(0x1cb64fde5a0) [debug ] 18:33:48.744 LibUvEventDispatcher::unregisterSocketNotifier() QSocketNotifier(0x1cb64fde5a0) [debug ] 18:33:48.782 LibUvEventDispatcher::registerSocketNotifier() QSocketNotifier(0x1cb64fde5a0) [debug ] 18:33:48.793 LibUvEventDispatcher::unregisterSocketNotifier() QSocketNotifier(0x1cb64fde5a0) [debug ] 18:33:48.831 LibUvEventDispatcher::registerSocketNotifier() QSocketNotifier(0x1cb64fde5a0) [debug ] 18:33:48.841 LibUvEventDispatcher::unregisterSocketNotifier() QSocketNotifier(0x1cb64fde5a0) [debug ] 18:33:48.879 LibUvEventDispatcher::registerSocketNotifier() QSocketNotifier(0x1cb64fde5a0) [debug ] 18:33:48.890 LibUvEventDispatcher::unregisterSocketNotifier() QSocketNotifier(0x1cb64fde5a0) [debug ] 18:33:48.927 LibUvEventDispatcher::registerSocketNotifier()
Re: [Interest] windeployqt
I believe that QtCore5’s broken sig is due to the funky patching windeployqt does to paths hardcoded in it.I never had problems with it though. It seems like a maybe QML related problem.If you don’t redirect qWarnings / qInfos somewhere you could always use SysInternal’s DebugView to ‘spy’ on debug outputs of the system and see if internal QML loader and / or parser spits something. Narolewski Jakub From: Jason HSent: 27 November 2019 19:57To: interestqt-project.orgSubject: [Interest] windeployqt I tried to use windeployqt to create a QML application directory structure to run on a system without Qt.I placed the resulting directory tree on the system and got nothing. Like I double clicked the .exe and nothing happened. So I went to the command line (cmd.exe) It just gave me the prompt back. No window was created. I loaded it up in depends.exe on the system that built it and I only noted two things:1. QtCore5.dll had an invalid signature2. The app was linking against i386 and x64 libraries. I don't know if those were the problems though. How do I debug this? ___Interest mailing listInterest@qt-project.orghttps://lists.qt-project.org/listinfo/interest ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] Static build of Qt - debug mode and plugins
Thank you Thiago for your suggestion :] I'm currently not able to use zstandard because I need it to work on my client side - WebGL targeted Unity Engine builds. We had some problems getting it to work using different approaches. As for compression performance, zstd is still not as fast as lz4's LZ4_compress_fast - at least not in my use case. I have generated some quick'n'very'dirty benchmarks if you want to take look at them: https://docs.google.com/spreadsheets/d/1akfTIbOjRladXbnZx1K8GyekKL5tCBAiBTS6jQ1v0OQ/edit?ouid=116212118529929666006=sheets_home=true The suspiciously similar payload sizes in case of zstd were due to clients inability to properly send their data back to the server - they did not change their positions on 2d plane that much. I can make zstd to 'run' as fast as lz4 if I pass '-100' as a compression level but resulting package size is bigger than lz4's. Dictionary mode is not helping much probably because I'm compressing flatbuffers structures containing only fast-changing numerical data - not much correlation in those. My project is targeting low grade VPS'es, akin to DigitalOcean's Droplets, so in a long run even small CPU time differences makes a difference to me. Jakub Narolewski From: Thiago Macieira Sent: 26 August 2019 07:40 To: interest@qt-project.org Subject: Re: [Interest] Static build of Qt - debug mode and plugins On Sunday, 25 August 2019 08:59:23 PDT Jakub Narolewski wrote: > # small hack to properly set LZ4 library between build modes Suggestion: if you are not required to use LZ4 because of a file format, you should switch to Zstandard. It compresses better *and* faster than LZ4. It requires more RAM to run, but if you're loading QtCore, QtNetwork and QtSql, memory usage is not your limitation. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel System Software Products ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] Static build of Qt - debug mode and plugins
Correct! Somewhat. I’m using VS under Windows configured to use ‘Unix Makefiles’ as generator when I’m connected to remote Linux boxes. Under Windows I use Ninja. Narolewski Jakub From: Elvis Stansvik Sent: 26 August 2019 18:54 To: Matthew Woehlke Cc: interest@qt-project.org Interest; Jakub Narolewski Subject: Re: Static build of Qt - debug mode and plugins Den mån 26 aug. 2019 kl 18:49 skrev Matthew Woehlke : > > On 26/08/2019 12.18, Elvis Stansvik wrote: > > Den mån 26 aug. 2019 17:32Matthew Woehlke skrev: > >> ...or just run `make VERBOSE=1`. > > > > I didn't know if he was using ninja or make, so suggested the solution that > > I believe will work with both (with recent versions of CMake) :) > > Fair point. I'm pretty sure the `[1%] ...` is not Ninja (Ninja would > normally be e.g. `[1/52] ...`), but it might have been Visual Studio. Ah yes, well spotted. It wasn't VS since it's Linux. So your Make assumption was probably correct. > > For some reason I took one look and immediately believed it to be > `make`, but now I think that was my bad :-). (Possibly related to how > often I use Windows these days... hardly ever. Also, when I do have to > use Windows, I still use Ninja ;-).) Amen. Elvis > > -- > Matthew ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] Static build of Qt - debug mode and plugins
Sound really awesome – the less steps the better. Does this feature already exist on the dev branch of qt? Can check it out by compiling Qt directly from git? Narolewski Jakub From: Alexandru Croitor Sent: 25 August 2019 20:07 To: Jakub Narolewski; Thiago Macieira; interest@qt-project.org Subject: Re: [Interest] Static build of Qt - debug mode and plugins Note that Qt 5.14 will come with support for importing static plugins from CMake, and you won't have to bother with the dependency order anymore. ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] Static build of Qt - debug mode and plugins
Ah yes, mystery solved. As usual – the butler did it. I suppose I should read
my own code more carefully.
In case of Release builds I’m adding “-flto” switch to the resulting object
using this line of code:
if (NOT CMAKE_BUILD_TYPE STREQUAL "Debug")
if (WIN32)
SET(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} /Ox /fp:fast")
endif (WIN32)
if (LINUX)
SET(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -flto
-funroll-all-loops -pthread")
endif (LINUX)
if (APPLE)
SET(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -flto")
endif (APPLE)
endif (NOT CMAKE_BUILD_TYPE STREQUAL "Debug")
When I also force it to exist in Debug builds the order of
target_link_libraries function does not matter anymore and application builds
just fine.
Sorry for the noise.
Thanks again for your help :]
Narolewski Jakub
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest
Re: [Interest] Static build of Qt - debug mode and plugins
Yea, it builds fine when I reorder them in my CMakeLists.
My ‘invalid’ CMakeLists part dealing with external libraries looks like this:
# global target link libraries
target_link_libraries(${TARGET_FULL_NAME}
PRIVATE
Qt5::Core
Qt5::Sql
Qt5::Network
Qt5::Concurrent
Qt5::WebSockets
${BOX2D_LIBRARY}
${LZ4_LIBRARY}
)
# on unix-based systems we use static qt build - add some stuff to target link
libraries
if (LINUX)
target_link_libraries(${TARGET_FULL_NAME}
PRIVATE
Qt5::QPSQLDriverPlugin
Qt5::QSQLiteDriverPlugin
"libpq.so"
)
endif()
# small hack to properly set LZ4 library between build modes
if (CMAKE_BUILD_TYPE STREQUAL "Debug")
(${TARGET_FULL_NAME} PRIVATE ${LZ4_LIBRARY_DEBUG})
else ()
target_link_libraries(${TARGET_FULL_NAME} PRIVATE
${LZ4_LIBRARY_RELEASE})
endif (CMAKE_BUILD_TYPE STREQUAL "Debug")
I don’t use any more target_link_libraries functions in there so I don’t know
from where this extra libQt5Network come from.
Do you have any idea why it actually builds this way under Release mode?
>From what I see, order of the libraries are the same between Release and Debug
>and only Debug generates those errors.
// RELEASE
/usr/local/Qt-5.13.0/lib/libQt5Core.a
/usr/local/Qt-5.13.0/lib/libQt5Sql.a
/usr/local/Qt-5.13.0/lib/libQt5Network.a
/usr/local/Qt-5.13.0/lib/libQt5Concurrent.a
/usr/local/Qt-5.13.0/lib/libQt5WebSockets.a
/home/izowiuz/vcpkg/installed/x64-linux/lib/libBox2D.a
/usr/local/Qt-5.13.0/plugins/sqldrivers/libqsqlpsql.a
/usr/local/Qt-5.13.0/plugins/sqldrivers/libqsqlite.a
-lpq
/home/izowiuz/vcpkg/installed/x64-linux/lib/liblz4.a
/usr/local/Qt-5.13.0/lib/libQt5Network.a
/usr/local/Qt-5.13.0/lib/libQt5Core.a -lpthread
/usr/local/Qt-5.13.0/lib/libQt5Network.a
/usr/local/Qt-5.13.0/lib/libQt5Core.a -lm
/usr/local/Qt-5.13.0/lib/libqtpcre2.a -ldl -lssl -lcrypto
// DEBUG
/usr/local/Qt-5.13.0/lib/libQt5Core.a
/usr/local/Qt-5.13.0/lib/libQt5Sql.a
/usr/local/Qt-5.13.0/lib/libQt5Network.a
/usr/local/Qt-5.13.0/lib/libQt5Concurrent.a
/usr/local/Qt-5.13.0/lib/libQt5WebSockets.a
/home/izowiuz/vcpkg/installed/x64-linux/debug/lib/libBox2D.a
/usr/local/Qt-5.13.0/plugins/sqldrivers/libqsqlpsql.a
/usr/local/Qt-5.13.0/plugins/sqldrivers/libqsqlite.a
-lpq
/home/izowiuz/vcpkg/installed/x64-linux/debug/lib/liblz4d.a
/usr/local/Qt-5.13.0/lib/libQt5Network.a
/usr/local/Qt-5.13.0/lib/libQt5Core.a -lpthread
/usr/local/Qt-5.13.0/lib/libQt5Network.a
/usr/local/Qt-5.13.0/lib/libQt5Core.a -lm
/usr/local/Qt-5.13.0/lib/libqtpcre2.a -ldl -lssl -lcrypto
Narolewski Jakub
From: Thiago Macieira
Sent: 25 August 2019 17:46
To: interest@qt-project.org
Subject: Re: [Interest] Static build of Qt - debug mode and plugins
On Sunday, 25 August 2019 00:25:50 PDT Jakub Narolewski wrote:
> /usr/local/Qt-5.13.0/lib/libQt5Core.a
> /usr/local/Qt-5.13.0/lib/libQt5Sql.a
> /usr/local/Qt-5.13.0/lib/libQt5Network.a
> /usr/local/Qt-5.13.0/lib/libQt5Concurrent.a
> /usr/local/Qt-5.13.0/lib/libQt5WebSockets.a
> /home/izowiuz/vcpkg/installed/x64-linux/lib/libBox2D.a
> /usr/local/Qt-5.13.0/plugins/sqldrivers/libqsqlpsql.a
> /usr/local/Qt-5.13.0/plugins/sqldrivers/libqsqlite.a
> -lpq
> /home/izowiuz/vcpkg/installed/x64-linux/lib/liblz4.a
> /usr/local/Qt-5.13.0/lib/libQt5Network.a
> /usr/local/Qt-5.13.0/lib/libQt5Core.a -lpthread
> /usr/local/Qt-5.13.0/lib/libQt5Network.a
> /usr/local/Qt-5.13.0/lib/libQt5Core.a -lm
> /usr/local/Qt-5.13.0/lib/libqtpcre2.a -ldl -lssl -lcrypto
The order is wrong, as you can see. libQt5Sql.a appears before the plugins.
Invert the order and make the plugins appear before the library in this link
line.
It's interesting that the order is mostly correct. It seems that CMake is
applying dependency sorting correctly. If that is the case, then either it's a
CMake bug or there's some information missing in the qmake-generated CMake
files. Reporting a bug here is unlikely to get you enough attention, so you
may want to get your hands dirty and debug yourself.
It's also interesting that QtCore and QtNetwork are listed three times.
--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel System Software Products
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest
Re: [Interest] Static build of Qt - debug mode and plugins
/ItemBox.cpp.o CMakeFiles/mrserver_debug.dir/src/World/Objects/Entity.cpp.o CMakeFiles/mrserver_debug.dir/src/World/Modes/TeamGameMode.cpp.o CMakeFiles/mrserver_debug.dir/src/World/Modes/Stats/DeathMatchStats.cpp.o CMakeFiles/mrserver_debug.dir/src/World/ContactListener.cpp.o CMakeFiles/mrserver_debug.dir/src/Server/Events/EventSignaler.cpp.o CMakeFiles/mrserver_debug.dir/src/Server/Events/ClientEvent.cpp.o CMakeFiles/mrserver_debug.dir/src/Utilities/b2Separator.cpp.o CMakeFiles/mrserver_debug.dir/src/Server/SlaveServer.cpp.o CMakeFiles/mrserver_debug.dir/src/World/Objects/Car.cpp.o CMakeFiles/mrserver_debug.dir/src/Server/AccountManager.cpp.o CMakeFiles/mrserver_debug.dir/src/Server/Server.cpp.o CMakeFiles/mrserver_debug.dir/src/World/Modes/Stats/GameModeStats.cpp.o CMakeFiles/mrserver_debug.dir/src/World/Objects/Drone.cpp.o CMakeFiles/mrserver_debug.dir/src/World/Road/RoadController.cpp.o CMakeFiles/mrserver_debug.dir/src/World/Road/RoadTraveler.cpp.o CMakeFiles/mrserver_debug.dir/src/Server/LoadoutManager.cpp.o CMakeFiles/mrserver_debug.dir/src/World/Weapons/ZigZagProjectile.cpp.o CMakeFiles/mrserver_debug.dir/src/World/Weapons/BounceProjectile.cpp.o CMakeFiles/mrserver_debug.dir/src/World/Objects/HealthPack.cpp.o CMakeFiles/mrserver_debug.dir/src/Server/TcpServer.cpp.o CMakeFiles/mrserver_debug.dir/src/DataContainers/moc_GameData.cpp.o CMakeFiles/mrserver_debug.dir/src/Server/moc_AccountManager.cpp.o CMakeFiles/mrserver_debug.dir/src/Server/Database/moc_SqlGameDataLoader.cpp.o CMakeFiles/mrserver_debug.dir/src/Server/Events/moc_EventSignaler.cpp.o CMakeFiles/mrserver_debug.dir/src/Server/moc_Room.cpp.o CMakeFiles/mrserver_debug.dir/src/Server/moc_TcpServer.cpp.o CMakeFiles/mrserver_debug.dir/src/Server/moc_Server.cpp.o CMakeFiles/mrserver_debug.dir/src/Server/moc_LoadoutManager.cpp.o CMakeFiles/mrserver_debug.dir/src/Server/moc_StatsManager.cpp.o CMakeFiles/mrserver_debug.dir/src/Server/moc_StatsManagerWorker.cpp.o CMakeFiles/mrserver_debug.dir/src/World/Modes/moc_GameMode.cpp.o CMakeFiles/mrserver_debug.dir/src/World/moc_World.cpp.o -o mrserver_debug /usr/local/Qt-5.13.0/lib/libQt5Core.a /usr/local/Qt-5.13.0/lib/libQt5Sql.a /usr/local/Qt-5.13.0/lib/libQt5Network.a /usr/local/Qt-5.13.0/lib/libQt5Concurrent.a /usr/local/Qt-5.13.0/lib/libQt5WebSockets.a /home/izowiuz/vcpkg/installed/x64-linux/debug/lib/libBox2D.a /usr/local/Qt-5.13.0/plugins/sqldrivers/libqsqlpsql.a /usr/local/Qt-5.13.0/plugins/sqldrivers/libqsqlite.a -lpq /home/izowiuz/vcpkg/installed/x64-linux/debug/lib/liblz4d.a /usr/local/Qt-5.13.0/lib/libQt5Network.a /usr/local/Qt-5.13.0/lib/libQt5Core.a -lpthread /usr/local/Qt-5.13.0/lib/libQt5Network.a /usr/local/Qt-5.13.0/lib/libQt5Core.a -lm /usr/local/Qt-5.13.0/lib/libqtpcre2.a -ldl -lssl -lcrypto In both cases I see that /usr/local/Qt-5.13.0/lib/libQt5Sql.a is listed before SQL plugins: libqsqlite.a and libqsqlpsql.a Nevertheless, when I changed the order of plugins and Qt's Sql component application started building properly in Debug mode. Thank you! Narolewski Jakub From: Elvis Stansvik Sent: 25 August 2019 09:09 To: Thiago Macieira Cc: interest@qt-project.org Interest Subject: Re: [Interest] Static build of Qt - debug mode and plugins Den sön 25 aug. 2019 kl 02:56 skrev Thiago Macieira : > > On Saturday, 24 August 2019 10:53:45 PDT Jakub Narolewski wrote: > > [ 1%] Linking CXX executable mrserver_debug > > Please expand this line. Jakub, to do this you can pass -DCMAKE_VERBOSE_MAKEFILE:BOOL=TRUE to CMake. Elvis > Since this is a static build, the order in which the > libraries is listed matters. > > Make sure that you list the plugin before the QtSql library. > > -- > Thiago Macieira - thiago.macieira (AT) intel.com > Software Architect - Intel System Software Products > > > > ___ > Interest mailing list > Interest@qt-project.org > https://lists.qt-project.org/listinfo/interest ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
[Interest] Static build of Qt - debug mode and plugins
Hello :] I'm having a bit of a problem compiling my application in debug build mode under Linux. Generally, under *nixes, I'm using self build, static Qt version. To configure Qt I'm using this simple one-liner: // CONFIGURE START ./configure \ -opensource \ -confirm-license \ -static \ -debug \ -openssl-linked \ -qt-zlib \ -qt-pcre \ -no-gui \ -no-dbus \ -no-accessibility \ -no-opengl \ -no-pkg-config \ -no-libjpeg \ -no-libpng \ -no-harfbuzz \ -no-freetype \ -no-xcb \ -no-xkbcommon \ -no-feature-xml \ -no-feature-testlib \ -no-feature-gif \ -no-feature-ico \ -no-feature-texthtmlparser \ -no-feature-textodfwriter \ -no-feature-effects \ -no-feature-im \ -no-feature-dom \ -no-feature-filesystemmodel \ -no-feature-graphicsview \ -no-feature-graphicseffect \ -no-feature-sizegrip \ -no-feature-calendarwidget \ -no-feature-printpreviewwidget \ -no-feature-keysequenceedit \ -no-feature-colordialog \ -no-feature-filedialog \ -no-feature-fontdialog \ -no-feature-printpreviewdialog \ -no-feature-progressdialog \ -no-feature-inputdialog \ -no-feature-errormessage \ -no-feature-wizard \ -no-feature-datawidgetmapper \ -no-feature-imageformat_bmp \ -no-feature-imageformat_ppm \ -no-feature-imageformat_xbm \ -no-feature-imageformat_png \ -no-feature-imageformat_jpeg \ -no-feature-image_heuristic_mask \ -no-feature-image_text \ -no-feature-colornames \ -no-feature-cups \ -no-feature-paint_debug \ -no-feature-freetype \ -no-feature-translation \ -no-feature-codecs \ -no-feature-big_codecs \ -no-feature-ftp \ -no-feature-bearermanagement \ -no-feature-completer \ -no-feature-fscompleter \ -no-feature-desktopservices \ -no-feature-mimetype \ -no-feature-systemtrayicon \ -no-feature-undocommand \ -no-feature-undostack \ -no-feature-undogroup \ -no-feature-undoview \ -no-feature-statemachine \ -nomake examples \ -nomake tests \ -skip qt3d \ -skip qtandroidextras \ -skip qtcanvas3d \ -skip qtcharts \ -skip qtconnectivity \ -skip qtdatavis3d \ -skip qtdeclarative \ -skip qtdoc \ -skip qtgamepad \ -skip qtgraphicaleffects \ -skip qtimageformats \ -skip qtlocation \ -skip qtmacextras \ -skip qtmultimedia \ -skip qtnetworkauth \ -skip qtpurchasing \ -skip qtquickcontrols \ -skip qtquickcontrols2 \ -skip qtscript \ -skip qtscxml \ -skip qtsensors \ -skip qtserialbus \ -skip qtserialport \ -skip qtspeech \ -skip qtsvg \ -skip qttools \ -skip qttranslations \ -skip qtvirtualkeyboard \ -skip qtwayland \ -skip qtwebchannel \ -skip qtwebengine \ -skip qtwebview \ -skip qtwinextras \ -skip qtx11extras \ -skip qtremoteobjects \ -skip qtxmlpatterns // CONFIGURE END Application compiles and runs fine - but only in Release mode. As soon as I switch to debug versions of Qt and app I'm getting errors: // ERRORS START [ 1%] Linking CXX executable mrserver_debug /usr/local/Qt-5.13.0/plugins/sqldrivers/libqsqlpsql.a(main.o): In function `QPSQLDriverPlugin::~QPSQLDriverPlugin()': /home/izowiuz/qt/qt-everywhere-src-5.13.0/qtbase/src/plugins/sqldrivers/psql/main.cpp:46: undefined reference to `QSqlDriverPlugin::~QSqlDriverPlugin()' /usr/local/Qt-5.13.0/plugins/sqldrivers/libqsqlpsql.a(main.o): In function `QPSQLDriverPlugin::~QPSQLDriverPlugin()': /home/izowiuz/qt/qt-everywhere-src-5.13.0/qtbase/src/plugins/sqldrivers/psql/main.cpp:46: undefined reference to `QSqlDriverPlugin::~QSqlDriverPlugin()' /usr/local/Qt-5.13.0/plugins/sqldrivers/libqsqlpsql.a(main.o): In function `QPSQLDriverPlugin::QPSQLDriverPlugin()': /home/izowiuz/qt/qt-everywhere-src-5.13.0/qtbase/src/plugins/sqldrivers/psql/main.cpp:58: undefined reference to `QSqlDriverPlugin::QSqlDriverPlugin(QObject*)' /usr/local/Qt-5.13.0/plugins/sqldrivers/libqsqlite.a(smain.o): In function `QSQLiteDriverPlugin::~QSQLiteDriverPlugin()': /home/izowiuz/qt/qt-everywhere-src-5.13.0/qtbase/src/plugins/sqldrivers/sqlite/smain.cpp:46: undefined reference to `QSqlDriverPlugin::~QSqlDriverPlugin()' /usr/local/Qt-5.13.0/plugins/sqldrivers/libqsqlite.a(smain.o): In function `QSQLiteDriverPlugin::~QSQLiteDriverPlugin()': /home/izowiuz/qt/qt-everywhere-src-5.13.0/qtbase/src/plugins/sqldrivers/sqlite/smain.cpp:46: undefined reference to `QSqlDriverPlugin::~QSqlDriverPlugin()' /usr/local/Qt-5.13.0/plugins/sqldrivers/libqsqlite.a(smain.o): In function `QSQLiteDriverPlugin::QSQLiteDriverPlugin()': /home/izowiuz/qt/qt-everywhere-src-5.13.0/qtbase/src/plugins/sqldrivers/sqlite/smain.cpp:58: undefined reference to `QSqlDriverPlugin::QSqlDriverPlugin(QObject*)' /usr/local/Qt-5.13.0/plugins/sqldrivers/libqsqlite.a(qsql_sqlite.o): In function `QSQLiteResult::virtual_hook(int, void*)': /home/izowiuz/qt/qt-everywhere-src-5.13.0/qtbase/src/plugins/sqldrivers/sqlite/qsql_sqlite.cpp:377: undefined reference to `QSqlCachedResult::virtual_hook(int, void*)' /usr/local/Qt-5.13.0/plugins/sqldrivers/libqsqlite.a(qsql_sqlite.o): In function `QSQLiteResultPrivate::QSQLiteResultPrivate(QSQLiteResult*, QSQLiteDriver const*)':
[Interest] Registering .pragma library files in custom QML plugins
Hello :]
My question is essentially something I already asked about on Qt's forums
sometime in 2018:
https://forum.qt.io/topic/89775/registering-pragma-singleton-libraries-in-custom-plugins
We set the requirements such as:
- project is an application which usues a bunch of my custom QML plugins
- plugins contains custom .qml components, QQuickItem-based components, .js
'.pragma library' components and all the other necessary stuff
- we want to 'properly' structure QML plugins
Currently, for a plugin called IzLibrary, I do:
- I register all my custom types / components using qmlRegisterType() functions
in my QQmlExtensionPlugin subclass
- I enable qmlcachegen to precompile QML stuff to binary stuff
- I provide qmldir file with contents to:
// QMLDIR FILE START
module IzLibrary
plugin IzLibraryPlugin
typeinfo IzLibrary.qmltypes
classname QmlPlugin
IzToast 1.0 qrc:///include/IzLibrary/JS/IzToast.js
IzMark 1.0 qrc:///include/IzLibrary/JS/IzMark.js
IzBusy 1.0 qrc:///include/IzLibrary/JS/IzBusy.js
IzObjectCreator 1.0 qrc:///include/IzLibrary/JS/IzObjectCreator.js
// QMLDIR FILE END
- finally, using custom CMake commands, I generate .qmltypes file for syntax
highlighting for my custom components and deploy all of this to the plugin's
destination
Now, the problem. I'm not able to preregister my .js .pragam library files
without 'IzMark 1.0 qrc:///include/IzLibrary/JS/IzMark.js' stuff in qmldir file.
I got this idea from Simon Hausmann, from his comment in this QTBUG:
https://bugreports.qt.io/browse/QTBUG-57074
"The suggested workaround of specifying a qrc path in the qmldir file is indeed
one perfectly fine way of solving this.
Another option - the path chosen by QtQuick Controls - is to not list all of
the components in the qmldir file but rather register them via
qmlRegisterType() API calls in the plugin's initialization - then using a qrc
path as well."
Which is working fine currently but, as described by Ulf Hermann, is considered
bad practice and actually generates warnings when loading such plugins:
https://bugreports.qt.io/browse/QTBUG-76955
Adding line:
qmlRegisterType(QUrl(QStringLiteral("qrc:/include/IzLibrary/JS/IzBusy.js")),
uri, 1, 0, "IzBusy");
crashes qmlplugindump during .qmltypes file generation and running my
application with such a plugin crashes it also.
So my questions are. Have I missed something silly? Do I have to register .js
files somewhat differently? Is this is currently possible to do?
Narolewski Jakub
Mentor, guru, bastion of modesty.
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest
Re: [Interest] QWebSocketServer - server randomly stopsacceptingconnections
Quick test and it looks like this is it. When I start my server in SSL mode and spam some ws connections at it I quickly loose ability to connect – even under Windows. What’s more, trying to connect to SSL server using ws protocol does not emit any errors on the server side. Can situation on my remote test server can be attributed to bots and / or scanners? Our client forces only wss connections, so something else has try to connect to it. Well, either this is QTBUG-57026 or some other, completely unrelated thing x] Hmm, this could be problematic. Either I will hack Qt sources or will try to use QTcpServer to hack around it. From: Jason H Sent: 04 April 2019 19:07 To: Jakub Narolewski Cc: interest@qt-project.org Subject: Re: RE: [Interest] QWebSocketServer - server randomly stopsacceptingconnections Wow, a P1 that was abandoned. https://codereview.qt-project.org/#/c/179030/ **facepalm** ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] QWebSocketServer - server randomly stops acceptingconnections
I just found this old report: https://bugreports.qt.io/browse/QTBUG-57026 which sounds suspiciously similar to what I am observing. Hmm, I wonder if you hit the jackpot writing earlier to use QTcpServer to initialize connections. If I could still use SSL with QWebSocketServer::handleConnection(QTcpSocket *socket) then this could be the solution :] Will test it and report back! From: Jason H Sent: 04 April 2019 17:49 To: Narolewski Jakub Cc: interest@qt-project.org Subject: Re: [Interest] QWebSocketServer - server randomly stops acceptingconnections 1. Add a slowloris attack to your fuzzer. Really. 2. "rejected" means something specific. The server does not reject your connection. Your client sends the RST packet. The "long periods" could just be those first few [hundred] connections where everything goes right, but the slow connection breaks it. I've actually seen this before in company proprietaty code. I wrote a local storage service - previously the storage server was remote - and the timing of packets broke the header parsing. This seems really similar in nature. It -no joke- expected that all the header data in the first packet and no additional data. However now that the service was lusing the localhost (loopback) interface it was no longer subject to MTU and nagle's algorythm. ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] QWebSocketServer - server randomly stops acceptingconnections
Hello Jason,
Thank you very much for your reply.
I’m not sure if I can / should directly attach binaries here. I’ve uploaded a
wireshark dump of the connection attempt at:
https://drive.google.com/open?id=1juNXd7pkI9Xryt_enjh6i2LWm3RL5iQV
I call listen() method with QHostAddress::Any parameter value:
m_wsServer->listen(QHostAddress::Any, m_port)
No proxy is used.
No other custom, network oriented software is running on this box. Only vanilla
stuff that came post VPS provisioning.
From: Jason H
Sent: 03 April 2019 18:23
To: Jakub Narolewski
Cc: interest@qt-project.org
Subject: Re: [Interest] QWebSocketServer - server randomly stops
acceptingconnections
What happens when you telnet to it?
Are you getting stuff (SYN_ACK) rom the OS, is the OS resetting (RST) the
connection?
Is this listening on localhost, virtual or a physical interface?
Linux is generally bad at power managment and networking and maybe that has
something to do with it? There is/was an issue with QNetworkAccessManager which
after the task got suspended, would not work anymore (I saw this mostly on
mobile OSs)
Is it proxied? i.e. behind NGINX?
Wireshark dump of a connection attemp while it's dead would really help.
Sent: Wednesday, April 03, 2019 at 11:59 AM
From: "Jakub Narolewski"
To: "interest@qt-project.org"
Subject: [Interest] QWebSocketServer - server randomly stops accepting
connections
I have this one, strange problem with QWebSocketServer that is driving me
insane.
My project is a very simple, websocket-based online game server. It uses Qt SQL
modules and makes use of some light QEvent'ing.
Up until recently I used uWebSockets to drive my wss communications. To make
matters simpler to me I decided to reimplement 'network' part of the
application using Qt native module - QWebSocketServer.
It generally works nice - it survives my naive fuzzing tech and cleanly
integrates with Qt's event loop.
But here is the thing.
It randomly, without any error, stops accepting incoming connections. This is
VERY hard for me to debug. It happens anywhere between 8 to about 60ish hours
after I start my debian unit with systemctl and is fixed immediately when I
restart it's service.
I'm connected to every possible error related signal from QWebSocketServer
interface, ssl or otherwise - nothing is emited when this happens.
When I ssh to my server I see nominal CPU and memory usage - no leaks, infinite
loops or other fun things.
I recently used QObject's timerEvent to spam some qInfos into sys logs. I log:
void i9ms::Server::dumpServerStatus() const
{
qInfo() << "[Server status]"
<< "isListening:" <<
m_wsServer->isListening()
<< "hasPendingConnections:" <<
m_wsServer->hasPendingConnections()
<< "errorString:" <<
m_wsServer->errorString();
}
Right now, at the time of writing this message, the server is 'frozen' for
about 5 hours and all I see in logs are lines:
Apr 03 16:56:12 vps504293 mrserver_release[22148]: [info ] [Server
status] isListening: true hasPendingConnections: false errorString: ""
Problem goes away when I return to uWebSockets-based wss implementation. I let
the test server run on it for weeks without problems.
I have tested this on Ubuntu 18.04.2 LTS and Debian 9 both provided 'as-is'
from my VPS provider - OVH.
I appreciate any feedback or help, have no idea where to go from here. I could
possibly try master or 5.12.X branches but this will force me to add 'another
configure step' for deployment and is not trival.
___ Interest mailing list
Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest
[Interest] QWebSocketServer - server randomly stops accepting connections
I have this one, strange problem with QWebSocketServer that is driving me
insane.
My project is a very simple, websocket-based online game server. It uses Qt SQL
modules and makes use of some light QEvent'ing.
Up until recently I used uWebSockets to drive my wss communications. To make
matters simpler to me I decided to reimplement 'network' part of the
application using Qt native module - QWebSocketServer.
It generally works nice - it survives my naive fuzzing tech and cleanly
integrates with Qt's event loop.
But here is the thing.
It randomly, without any error, stops accepting incoming connections. This is
VERY hard for me to debug. It happens anywhere between 8 to about 60ish hours
after I start my debian unit with systemctl and is fixed immediately when I
restart it's service.
I'm connected to every possible error related signal from QWebSocketServer
interface, ssl or otherwise - nothing is emited when this happens.
When I ssh to my server I see nominal CPU and memory usage - no leaks, infinite
loops or other fun things.
I recently used QObject's timerEvent to spam some qInfos into sys logs. I log:
void i9ms::Server::dumpServerStatus() const
{
qInfo() << "[Server status]"
<< "isListening:" << m_wsServer->isListening()
<< "hasPendingConnections:" <<
m_wsServer->hasPendingConnections()
<< "errorString:" << m_wsServer->errorString();
}
Right now, at the time of writing this message, the server is 'frozen' for
about 5 hours and all I see in logs are lines:
Apr 03 16:56:12 vps504293 mrserver_release[22148]: [info] [Server
status] isListening: true hasPendingConnections: false errorString: ""
Problem goes away when I return to uWebSockets-based wss implementation. I let
the test server run on it for weeks without problems.
I have tested this on Ubuntu 18.04.2 LTS and Debian 9 both provided 'as-is'
from my VPS provider - OVH.
I appreciate any feedback or help, have no idea where to go from here. I could
possibly try master or 5.12.X branches but this will force me to add 'another
configure step' for deployment and is not trival.
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest
