Build failure in the absence of QtWidget #977
Comments
|
Widgets is required to build the GammaRay UI. Have you tested your proposed fix or tried to build without UI? |
|
I was trying to package GammaRay for https://github.com/toltec-dev/toolchain to I am not sure that the change I propose are working as expected. On the one hand |
|
oops yes my mistake. |
|
the loading of |
|
I think so: |
|
weird, |
|
@mattkdab The change being proposed by Etn40ff is correct and should be committed into GammaRay. As for the rest of the issue, it all boils down to the missing or unaligned symbols... I thought for a moment that xochitl might be statically compiled, which would prevent plugins from loading on GammaRay making it unusable in this situation; but that is not the case, as we can see by looking at the file extension of the libraries returned by nm (.so meaning dynamic loaded libraries). The actual cause for this bug would lie somewhere in-between the CMakeLists.txt files of those plugins, the meta-programming being referenced by qFatal, the following plugin's loading error: The qFatal's line being quoted is different from the line making the assertion: The quoted line resolves to That means QWindow is unavailable from within GuiSupport, which makes no sense considering it's imported in the very file (guisupport.cpp), which is a part of gammaray_guisupport_srcs in the plugin's CMakeLists.txt, which suggests the problem isn't in GammaRay's code, but somewhere on the toolchain. My working hypothesis is that the version of Qt used to build xochitl doesn't exactly match the one found in the one on the Toltec Qt Docker toolchain. Since xochitl is a part of Remarkable tablet, and very likely not built using that toolchain, this has some probability to it. I don't know of a quick way to confirm this theory. @Etn40ff What I'd do is go through previous versions of the toolkit, all the way back to the last toolkit that was officially published by Remarkable (which can be found here), and see on which version does it work, if any does match and this turns out to be the cause. |
|
@Etn40ff Another KDABian, David Faure, says that one case where the QGuiApplication::sessionId() const symbol is missing is when Qt is built with QT_NO_SESSIONMANAGER. Try compiling GammaRay with plugins/guisupport/guisupport.cpp:192: |
|
I just gave your suggestions a spin without much success. I tried with several instances of toltec's toolchain and various sysroots and also commented out line 192 in guisupport.cpp. Neither test had any effect. I will try to setup the toolchain you mentioned to see if anything happens. |
|
Things are more promising with the official toolchain that you can get from here: https://remarkable.guide/devel/toolchains.html#installer GammaRay does not compile with it because one of the two proplematic symbols is not there. Once I fix this probably it will fail for the other. |
|
GammaRay's CMake is finding that you have Qt 5 available in this toolkit, which allows Let us know if you get other errors like this, because it's just a matter of using a different and better way to tell which mayor version of Qt is actually being used. Make sure that you know which version of Qt is being used by the app you want to inspect. If the version doesn't exactly match, GammaRay won't inject or randomly crash during use. |
Fixes #977 by making suggested change to connect to QCoreApplication
Fixes #977 by making suggested change to connect to QCoreApplication
|
@Etn40ff Try again with the latest master. There should be no errors like the one you experienced yesterday and I've included the change proposed in your first comment. If anything is left to be resolved it should be the issue with the missing symbols. |
|
Thanks again for your support. Things are better but not working yet. With a qt5 toolchain: and with a Qt6 toolchain: |
|
@Etn40ff It looks like the Qt 5 toolchain is actually trying to build with Qt 6, because otherwise QNetworkConfiguration would've been found as it was only removed in Qt 6. In the same way, it looks like the Qt 6 toolchain is trying to build with Qt 5, because Try passing |
|
I tried without success: I got precisely the same two errors. If what you say about relocation is correct something is fishy about these toolchains: Is it possible that |
|
Hmm... No, you're right, I mistakenly compared source paths against binary paths. Now that I check again, both paths remain consistent across all versions of Qt (checked from 5.10.1 to 6.7.0).
|
|
I am still trying to figure out why is this not compiling. As it turns out |
|
@Etn40ff Try specifying -DCMAKE_PREFIX_PATH=path/to/toolchain/root -DCMAKE_INSTALL_PREFIX=path/to/sysroot on your first call to cmake. That'll have cmake find the dependencies needed to compile the software and place the binaries on your desired sysroot when you run cmake --install. |
|
https://github.com/toltec-dev/toolchain/blob/faa26ae58cc1cc1222f8ef2b7090cee8bb82c554/qt/Dockerfile#L6-L47
xochitl does have some statically compiled libraries. I don't expect that they would cause issues, but there is a chance that they are implementing something here that obfuscates the symbols so they are no longer in use. |
As long as Qt libraries aren't among the statically compiled libraries it should be fine. |
Compilation fails if
QtWidgetis not available.To reproduce, for example, try to compile with https://github.com/toltec-dev/toolchain:
This happens because there is no
#ifdef HAVE_QT_WIDGETSaround lines 354 and 355 inlauncher/cli/main.cpp.I suppose when
QtWidgetis not available these should instead read?The text was updated successfully, but these errors were encountered: