| Summary: | lxqt-base/lxqt-config-0.10.0 compilation failure : qiconloader_p.h not found | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | orionbelt2 |
| Component: | Current packages | Assignee: | LxQt maintainers <lxqt> |
| Status: | RESOLVED TEST-REQUEST | ||
| Severity: | normal | CC: | chiitoo, polidevk.polidevk |
| Priority: | Normal | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Attachments: |
Build log
Hack to allow for a successful compilation. |
||
|
Description
orionbelt2
2016-09-29 01:52:15 UTC
The problem seems to be with line: #include <private/qtxdg/qiconloader_p.h> which appears in two files: /var/tmp/portage/lxqt-base/lxqt-config-0.10.0/work/lxqt-config-0.10.0/lxqt-config-appearance/iconthemeconfig.cpp and /var/tmp/portage/lxqt-base/lxqt-config-0.10.0/work/lxqt-config-0.10.0/lxqt-config-appearance/iconthemeinfo.cpp Using "locate qiconloader_p", i found only these two instances of this file: /usr/include/qt4/QtGui/private/qiconloader_p.h /usr/include/qt5/QtGui/5.6.1/QtGui/private/qiconloader_p.h For this project we need qt5, but /usr/include/qt5/QtGui/5.6.1/QtGui/ is not included in the -isystem parameters of the build, only /usr/include/qt5/QtGui is. And, there is no qtxdg. I altered the #include line to make it: #include <5.6.1/QtGui/private/qiconloader_p.h> but it did not work: Now it was complaining about the next line "using namespace QtXdg;", saying that it is not a namespace-name, so it's probably not reading the right header file... I also tried: #include <private/xdgiconloader/xdgiconloader_p.h> from dev-libs/libqtxdg (to satisfy the qtxdg part...) but it didn't work either. So it must be something more serious. I hope someone can look into it soon... Created attachment 448680 [details, diff]
Hack to allow for a successful compilation.
Removing the namespace and 'qtxdg' from includes in the two files allows for a successful compilation, but I have no idea what it might (most likely will?) break. :]
It fails with =dev-libs/libqtxdg-2.0.0 but works fine with =dev-libs/libqtxdg-1.3.0 I followed Chiitoo's suggestion, and the build was completed successfully. I have been running LXQt for more than a day now without having seen any obvious malfunction due to removing the namespace and the includes. But if it works with dev-libs/libqtxdg-1.3.0 as Richard Nespithal pointed out, perhaps 1.3.0 should become stable? Note that libqtxdg is not included among the packages that must be keyworded on Gentoo's LXQt instructions page: https://wiki.gentoo.org/wiki/LXQt but portage asks so since there's no stable version. Version 0.11.0 seems like it might fix this properly (and it's getting into Portage little by little now). Here's one of the particular commits that make me think so: https://github.com/lxde/lxqt-config/commit/304d5e55800c7a8d77585b739e6a36ec20b99102 0.11.0 in tree now The original bug seems to have vanished, but compilation of lxqt-base/lxqt-config-0.11.0 now fails for me due to another header file: cd /var/tmp/portage/lxqt-base/lxqt-config-0.11.0/work/lxqt-config-0.11.0_build/lxqt-config-appearance && /usr/bin/x86_64-pc-linux-gnu-g++ -DLXQT_DATA_DIR=\"/usr/share\" -DLXQT_ETC_XDG_DIR=\"/etc/xdg\" -DLXQT_GRAPHICS_DIR=\"/usr/share/lxqt/graphics\" -DLXQT_RELATIVE_SHARE_DIR=\"lxqt\" -DLXQT_RELATIVE_SHARE_TRANSLATIONS_DIR=\"lxqt/translations\" -DLXQT_SHARE_DIR=\"/usr/share/lxqt\" -DLXQT_SHARE_TRANSLATIONS_DIR=\"/usr/share/lxqt/translations\" -DLXQT_VERSION=\"0.11.0\" -DQT_CORE_LIB -DQT_DBUS_LIB -DQT_GUI_LIB -DQT_NO_DEBUG -DQT_SVG_LIB -DQT_USE_QSTRINGBUILDER -DQT_WIDGETS_LIB -DQT_X11EXTRAS_LIB -DQT_XML_LIB -I/var/tmp/portage/lxqt-base/lxqt-config-0.11.0/work/lxqt-config-0.11.0_build/lxqt-config-appearance -I/var/tmp/portage/lxqt-base/lxqt-config-0.11.0/work/lxqt-config-0.11.0/lxqt-config-appearance -I/var/tmp/portage/lxqt-base/lxqt-config-0.11.0/work/lxqt-config-0.11.0_build/lxqt-config-appearance/lxqt-config-appearance_autogen/include -I/usr/include/qt5/QtGui/5.7.1 -I/usr/include/qt5/QtGui/5.7.1/QtGui -I/usr/include/qt5/QtCore/5.7.1 -I/usr/include/qt5/QtCore/5.7.1/QtCore -I/var/tmp/portage/lxqt-base/lxqt-config-0.11.0/work/lxqt-config-0.11.0/lxqt-config-appearance/../liblxqt-config-cursor -I/var/tmp/portage/lxqt-base/lxqt-config-0.11.0/work/lxqt-config-0.11.0_build/lxqt-config-appearance/../liblxqt-config-cursor -isystem /usr/include/qt5 -isystem /usr/include/qt5/QtWidgets -isystem /usr/include/qt5/QtGui -isystem /usr/include/qt5/QtCore -isystem /usr/lib64/qt5/mkspecs/linux-g++ -isystem /usr/include/qt5/QtX11Extras -isystem /usr/include/qt5/QtXml -isystem /usr/include/lxqt -isystem /usr/include/lxqt/LXQt -isystem /usr/include/KF5/KWindowSystem -isystem /usr/include/KF5 -isystem /usr/include/qt5/QtDBus -isystem /usr/include/qt5xdg -isystem /usr/include/qt5xdgiconloader -isystem /usr/include/qt5xdgiconloader/2.0.0 -isystem /usr/include/qt5/QtSvg -DNDEBUG -march=core2 -O2 -pipe -fno-exceptions -Wall -std=c++11 -fPIE -fvisibility=hidden -fvisibility-inlines-hidden -fPIC -std=gnu++11 -o CMakeFiles/lxqt-config-appearance.dir/iconthemeconfig.cpp.o -c /var/tmp/portage/lxqt-base/lxqt-config-0.11.0/work/lxqt-config-0.11.0/lxqt-config-appearance/iconthemeconfig.cpp In file included from /var/tmp/portage/lxqt-base/lxqt-config-0.11.0/work/lxqt-config-0.11.0/lxqt-config-appearance/main.cpp:37:0: /var/tmp/portage/lxqt-base/lxqt-config-0.11.0/work/lxqt-config-0.11.0/lxqt-config-appearance/../liblxqt-config-cursor/selectwnd.h:26:26: fatal error: ui_selectwnd.h: No such file or directory compilation terminated. Using "locate" and an explicit search in /usr/include i fail to find any file named ui_selectwnd.h . [ PS: I don't know if i should have created a new bug report... ] Well if this isn't a coincidence, I don't know what is. :] Just 40 minutes or so ago, I created a pull request here: https://github.com/gentoo/gentoo/pull/4463 I haven't tested with 0.11.0, but the error seems very similar, if not identical to what the patch I added to 'lxqt-base/lxqt-config' there fixes, so you could give that a try. And yeah, a new bug would probably have been more appropriate, since this doesn't seem like exactly the same issue (then again, I would probably not have noticed the new bug, but I did notice this one due to CC). :] |
