Do others share my experiences: Qt has become cumbersome to build/install
-
@BwvB
Sad to read that Qt frustrates you increasingly.
I don't share such experiences, however. Probably not very surprising.
Can you break your encounters down into something more concrete?
Versions, operating systems, error messages, bug reports? -
Hi Axel, thanks for responding.
Yesterday, I filed a bugreport (https://bugreports.qt.io/browse/QTBUG-120141).
An unrelated, but similar issue only occurring when static linking I filed some time earlier.There was a compile error in the file
./qt3d/src/3rdparty/assimp/src/code/AssetLib/FBX/FBXBinaryTokenizer.cpp
I had to add #include <cstdint> to make it compile again.
Not reported.As for the warnings: I just ran ./configure (release mode), doing nothing special. I get many warning in 3rd party code. I just wonder if you don't see those. I appreciate this is mostly 3rd party code, but the warnings are so many, and not obviously harmless. It would improve Qt's image to iron them out instead of having such a noisy installation.
Complaints about qpa plugins (?) not present: these appear sometimes when I install a new version. I have no clue what they mean. . You only notice this after installation. It ussally means blindly installing everything that contains e.g. 'xcb' or something like that, and hope for the best. with no guarantee it is going to work after hours of compilation.
qtwebengine: I cannot answer that right away. Currrently I have no qt-machine available. Maybe later.
I have recent versions of both clang++ (18.0.0) and g++ (13.2.1) on my openSuse leap 15.5 machines (2 machines, both show similar issues with QT).
My list could have been longer, but I have not consistently archived or reported all issues. Sorry.
But together it underpins my experience that building Qt has become cumbersome, often taking at least half a day or longer just to have everything built, installed and working with my applications.
If interest is there, I could investigate more if that helps ironing out these issues.Kind Regards,
Bertwim -
Hi Axel, thanks for responding.
Yesterday, I filed a bugreport (https://bugreports.qt.io/browse/QTBUG-120141).
An unrelated, but similar issue only occurring when static linking I filed some time earlier.There was a compile error in the file
./qt3d/src/3rdparty/assimp/src/code/AssetLib/FBX/FBXBinaryTokenizer.cpp
I had to add #include <cstdint> to make it compile again.
Not reported.As for the warnings: I just ran ./configure (release mode), doing nothing special. I get many warning in 3rd party code. I just wonder if you don't see those. I appreciate this is mostly 3rd party code, but the warnings are so many, and not obviously harmless. It would improve Qt's image to iron them out instead of having such a noisy installation.
Complaints about qpa plugins (?) not present: these appear sometimes when I install a new version. I have no clue what they mean. . You only notice this after installation. It ussally means blindly installing everything that contains e.g. 'xcb' or something like that, and hope for the best. with no guarantee it is going to work after hours of compilation.
qtwebengine: I cannot answer that right away. Currrently I have no qt-machine available. Maybe later.
I have recent versions of both clang++ (18.0.0) and g++ (13.2.1) on my openSuse leap 15.5 machines (2 machines, both show similar issues with QT).
My list could have been longer, but I have not consistently archived or reported all issues. Sorry.
But together it underpins my experience that building Qt has become cumbersome, often taking at least half a day or longer just to have everything built, installed and working with my applications.
If interest is there, I could investigate more if that helps ironing out these issues.Kind Regards,
Bertwim@BwvB
Hi Bertwin,
Thanks for the bug report. Looks really strange and I began to ask myself if it shouldn’t actually test for the warning to occur. I’ll follow up on it.
I also use openSuSE, but Tumbleweed, as my daily working environment. I even build sometimes with all-warnings-are-errors and I build almost daily. I wonder why I don’t fall over that uninitialised pointer.
I can just encourage you to file bugs or turn to the mailing lists with specific problems.
Cheers
AxelSoftware Engineer
The Qt Company, Oslo -
@BwvB
Hi Bertwin,
Thanks for the bug report. Looks really strange and I began to ask myself if it shouldn’t actually test for the warning to occur. I’ll follow up on it.
I also use openSuSE, but Tumbleweed, as my daily working environment. I even build sometimes with all-warnings-are-errors and I build almost daily. I wonder why I don’t fall over that uninitialised pointer.
I can just encourage you to file bugs or turn to the mailing lists with specific problems.
Cheers
AxelThe problem with the
assimplibrary was fixed upstream already, need to sync it locally. Such include problems happen from time to time when the compiler devs decide to do some include cleanup. Then newer compiler will complain about missing includes as we can see here. Nothing we (or someone else) can do against this except reporting a bug or even better providing a patch for it. It will be fixed in 6.6.2 and 6.7.0.
https://bugreports.qt.io/browse/QTBUG-114239 -
Hi Axel, thanks for responding.
Yesterday, I filed a bugreport (https://bugreports.qt.io/browse/QTBUG-120141).
An unrelated, but similar issue only occurring when static linking I filed some time earlier.There was a compile error in the file
./qt3d/src/3rdparty/assimp/src/code/AssetLib/FBX/FBXBinaryTokenizer.cpp
I had to add #include <cstdint> to make it compile again.
Not reported.As for the warnings: I just ran ./configure (release mode), doing nothing special. I get many warning in 3rd party code. I just wonder if you don't see those. I appreciate this is mostly 3rd party code, but the warnings are so many, and not obviously harmless. It would improve Qt's image to iron them out instead of having such a noisy installation.
Complaints about qpa plugins (?) not present: these appear sometimes when I install a new version. I have no clue what they mean. . You only notice this after installation. It ussally means blindly installing everything that contains e.g. 'xcb' or something like that, and hope for the best. with no guarantee it is going to work after hours of compilation.
qtwebengine: I cannot answer that right away. Currrently I have no qt-machine available. Maybe later.
I have recent versions of both clang++ (18.0.0) and g++ (13.2.1) on my openSuse leap 15.5 machines (2 machines, both show similar issues with QT).
My list could have been longer, but I have not consistently archived or reported all issues. Sorry.
But together it underpins my experience that building Qt has become cumbersome, often taking at least half a day or longer just to have everything built, installed and working with my applications.
If interest is there, I could investigate more if that helps ironing out these issues.Kind Regards,
BertwimUpdate:
Yesterday, I filed a bugreport (https://bugreports.qt.io/browse/QTBUG-120141).
The fix for this will merge tonight.@Christian-Ehrlicher said in Do others share my experiences: Qt has become cumbersome to build/install:
Thanks Christian for pointing this out.
A colleague of mine is dealing with it. Should also be fixed shortly. -
Hi,
As a long-time C++ developer and Qt user (with great satisfaction) my experiences with building/installing Qt from the source code have gone the wrong way, the latest couple of editions. This posting is not a cry for help with a particular problem. Nor is it meant as a general rant on Qt. On the contrary, I like Qt and I am dependent on it. But I experience so many issues that upgrading to a new version is now a major effort -and in fact prevents me from doing that) whereas it used to be a straightforward process-though time consuming due to the Qt size. I am just curious if others have similar experiences.
What I experience:
- blunt compilation errors: (e.g. 6.6.1, shared, failed because std::uint32 was not recognised by the compiler (#include <cstdint> missing)
- Many warnings, not clear how serious these are. Although most of these appear in 3rdparty code, it doesn't help building confidence that the Qt version one is building is a robust product..
- As for QWebEngine: I have given up. True, it is a big component and there are a lot of dependencies. I am used to resolve these issues, but with QWebEngine I have thrown the towel in the ring. Even when all of them have been addressed, and all dependencies have been installed, Qt still didn't find some of them. I wanted to do some explorations with the webengine, but have dropped this plan.
- To facilitate deployment, I prefer to use the static versions of the qt-libs on final products. Building and linking with the static version of Qt is an exercise that usually fails initially. With 6.5.1 I finally got it working. The versions after that (6.6.0 and 6.6.1 produce error messages (on the same machine) when building makefiles with cmake and I can't get my application built.)
- Several times I had, after building qt without problems, that some xcb-related stuff prevented Qt from being run, whereas a previous version ran flawless.
Curious to hear other experiences.
Kind Regards,
BertwimHi,
also not my experience, but fair. Just want to point out one thing:
@BwvB said in Do others share my experiences: Qt has become cumbersome to build/install:
when building makefiles with cmake
If that means that you're using the Makefile generator of cmake, this is only 'community supported' currently, and as such might be a source of all kinds of issues. The only officially supported build is with -GNinja / ninja.
-
Hi,
also not my experience, but fair. Just want to point out one thing:
@BwvB said in Do others share my experiences: Qt has become cumbersome to build/install:
when building makefiles with cmake
If that means that you're using the Makefile generator of cmake, this is only 'community supported' currently, and as such might be a source of all kinds of issues. The only officially supported build is with -GNinja / ninja.
@kkoehne Ah, sorry. My mistake. I do use the ninja version.
One of the good things about Qt, is that the dev-team is taking issues seriously. I really appreciate this. It shows a professional attitude. The responses from Qt in this thread just show that.
Regards,
Bertwim -
@kkoehne Ah, sorry. My mistake. I do use the ninja version.
One of the good things about Qt, is that the dev-team is taking issues seriously. I really appreciate this. It shows a professional attitude. The responses from Qt in this thread just show that.
Regards,
Bertwim@BwvB I would like to point out
in OP it is nicely stated that the intent of the post isNOT seeking help
and
it is NOT a rantso
why it is NOT moved to
lounge ?( oh yes, it is not mine post so it is not moved ...)
My lounge comment would be
it is your business to build QT "from scratch"...if QT developers have to be notified specific way , in specific forum , with specific bug, about USERS issues...
it is their business ,however, ,"they care , about THEIR products ( livelihood ) " is gross overstatement ( my opinion ) .
-
@BwvB
Hi Bertwin,
Thanks for the bug report. Looks really strange and I began to ask myself if it shouldn’t actually test for the warning to occur. I’ll follow up on it.
I also use openSuSE, but Tumbleweed, as my daily working environment. I even build sometimes with all-warnings-are-errors and I build almost daily. I wonder why I don’t fall over that uninitialised pointer.
I can just encourage you to file bugs or turn to the mailing lists with specific problems.
Cheers
Axel@Axel-Spoerl On your question why you don't experience the issue with the uninitialised pointer, while you are building qt daily: I think this is because this problem does not show-up while building Qt, but when you do a 'cmake' of a project where a static qt linkage is required. In the find_package command, apparently only then the xxxxx.cmake file is used. You get a long, but otherwise reasonably clear message what is wrong.
-
@Axel-Spoerl On your question why you don't experience the issue with the uninitialised pointer, while you are building qt daily: I think this is because this problem does not show-up while building Qt, but when you do a 'cmake' of a project where a static qt linkage is required. In the find_package command, apparently only then the xxxxx.cmake file is used. You get a long, but otherwise reasonably clear message what is wrong.
@BwvB
That's spot on. I ran a static build out of shere interest last night, to find out what you suspect I would find out :-)
Anyway, it's fixed. Thanks for reporting.
And sorry about @AnneRanch's strange post. I hope it hasn't insulted you. -
@BwvB
That's spot on. I ran a static build out of shere interest last night, to find out what you suspect I would find out :-)
Anyway, it's fixed. Thanks for reporting.
And sorry about @AnneRanch's strange post. I hope it hasn't insulted you.@Axel-Spoerl Great it has been fixed. I am not offended by the other post. I really appreciate the constructive response of qt people!
-
@Axel-Spoerl On your question why you don't experience the issue with the uninitialised pointer, while you are building qt daily: I think this is because this problem does not show-up while building Qt, but when you do a 'cmake' of a project where a static qt linkage is required. In the find_package command, apparently only then the xxxxx.cmake file is used. You get a long, but otherwise reasonably clear message what is wrong.
@BwvB The problem is the huge amount of possibilities of different compilers, os and others - Qt CI can only test shared builds on 16 different platforms with 48 configurations. see e.g. https://testresults.qt.io/coin/integration/qt/qtbase/tasks/1705338888
-
B BwvB has marked this topic as solved on
