Created attachment 918033 [details] emerge --info '=dev-qt/qtbase-6.8.1::gentoo' QT_HOST_PATH=/usr/lib64/qt6 powerpc64-unknown-linux-gnu-emerge -a dev-qt/qtbase fails with the following output: ``` ... -- Detecting C compile features -- Detecting C compile features - done -- CMAKE_BUILD_TYPE was already explicitly set to: 'RelWithDebInfo' CMake Error at cmake/QtPublicDependencyHelpers.cmake:248 (find_package): Could not find a package configuration file provided by "Qt6HostInfo" with any of the following names: Qt6HostInfoConfig.cmake qt6hostinfo-config.cmake Add the installation prefix of "Qt6HostInfo" to CMAKE_PREFIX_PATH or set "Qt6HostInfo_DIR" to a directory containing one of the above files. If "Qt6HostInfo" provides a separate development package or SDK, be sure it has been installed. Call Stack (most recent call first): cmake/QtBuildHelpers.cmake:347 (_qt_internal_find_host_info_package) cmake/QtBuildHelpers.cmake:449 (qt_internal_setup_find_host_info_package) cmake/QtBuild.cmake:4 (qt_internal_setup_build_and_global_variables) cmake/QtSetup.cmake:6 (include) cmake/QtBuildRepoHelpers.cmake:21 (include) cmake/QtBuildRepoHelpers.cmake:232 (qt_build_internals_set_up_private_api) cmake/QtBaseHelpers.cmake:154 (qt_build_repo_begin) CMakeLists.txt:31 (qt_internal_qtbase_build_repo) ... ``` Same results I get setting QT_HOST_PATH=/usr/lib64/qt6/bin IMHO when cross compiling, dev-qt/qtbase should pull all the host tools and set QT_HOST_PATH.
QT_HOST_PATH=/usr did the trick! Though IMHO when cross compiling dev-qt/qtbase it should depend on (host) dev-qt/qtbase
(In reply to BogDan from comment #1) > QT_HOST_PATH=/usr did the trick! > Though IMHO when cross compiling dev-qt/qtbase it should depend on (host) > dev-qt/qtbase Unfortunately cannot really do that, on a normal system it'd depend on itself which doesn't work (when not cross-compiling, BDEPEND and DEPEND are the same thing). Recall there's been talk of doing USE=cross-compile or so for such issues in the past but it's not that simple. That aside, cross and Qt isn't something I'm really planning to work on myself, but can keep this open for reference when someone wants to.
(In reply to BogDan from comment #1) > QT_HOST_PATH=/usr did the trick! > Though IMHO when cross compiling dev-qt/qtbase it should depend on (host) > dev-qt/qtbase I've set export QT_HOST_PATH=/ when doing a cross. It works for almost all packages.
I'll add -DQT_HOST_PATH=${BROOT}/usr to the ebuild regardless. I plan to address the dependency issue in EAPI 9. Need to figure out the other bug first though.
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=a631496f102c4b1dbc40e643eccb7f477fd24e53 commit a631496f102c4b1dbc40e643eccb7f477fd24e53 Author: James Le Cuirot <chewi@gentoo.org> AuthorDate: 2025-02-20 22:37:13 +0000 Commit: James Le Cuirot <chewi@gentoo.org> CommitDate: 2025-02-20 22:37:46 +0000 dev-qt/qtbase: Fix cross-compiling with some CMake variables Closes: https://bugs.gentoo.org/942359 Closes: https://bugs.gentoo.org/949214 Signed-off-by: James Le Cuirot <chewi@gentoo.org> dev-qt/qtbase/qtbase-6.8.2-r2.ebuild | 6 ++++++ dev-qt/qtbase/qtbase-6.8.9999.ebuild | 6 ++++++ dev-qt/qtbase/qtbase-6.9.9999.ebuild | 8 +++++++- dev-qt/qtbase/qtbase-6.9999.ebuild | 8 +++++++- 4 files changed, 26 insertions(+), 2 deletions(-)
Will any of these variables cause problems when this Qt becomes used on the host? I ask because qtbase "remembers" options it was built it for other dev-qt/* packages (e.g. if you enable building tests on qtbase, then every dev-qt/* will build tests too even if you don't pass -DQT_BUILD_TESTS=ON again), and if options needs to change then we need to explicitly override it in qt6-build.eclass instead. Aka, suppose that this cross-compiled ESYSROOT gets used on the real machine later, it may still try to use -DQT_HOST_PATH=${BROOT}/usr "unless" qtbase is rebuilt on that machine (tc-is-cross-compiler will be false then). Untested but could result in other dev-qt/* thinking they're "still" being cross-compiled or use the wrong path given the remembered BROOT/usr could point to the old machine's ROOT. If passing either QT_HOST_PATH=/usr or =/broken/path plus the other variables for qtpaths is harmless when not cross-compiling, then it's probably not a big deal though. Thankful for the tc-is-cross-compiler that guards them though, given plans were to stabilize 6.8.2 today and didn't want to inspect if variables were potentially harmful for the host :)
(either way this better than being completely broken for cross, so I wouldn't stress too much about it)
(In reply to Ionen Wolkens from comment #6) > Will any of these variables cause problems when this Qt becomes used on the > host? Unfortunately, there is a little bit of that. I grepped across the installed files. The few instances found in binaries are probably benign. The most troubling instances are these. > /mnt/quartz/usr/lib64/qt6/mkspecs/modules/qt_lib_gui_private.pri:QMAKE_INCDIR_ATSPI = /mnt/quartz/usr/include/at-spi-2.0 /mnt/quartz/usr/include/dbus-1.0 /mnt/quartz/usr/lib64/dbus-1.0/include /mnt/quartz/usr/include/elogind /mnt/quartz/usr/lib64/libffi/include /mnt/quartz/usr/include/glib-2.0 /mnt/quartz/usr/lib64/glib-2.0/include /mnt/quartz/usr/include/libmount /mnt/quartz/usr/include/blkid > /mnt/quartz/usr/lib64/qt6/mkspecs/modules/qt_lib_gui_private.pri:QMAKE_INCDIR_DRM = /mnt/quartz/usr/include/libdrm /mnt/quartz/usr/include/drm > /mnt/quartz/usr/lib64/qt6/mkspecs/modules/qt_lib_gui_private.pri:QMAKE_INCDIR_FREETYPE = /mnt/quartz/usr/include/freetype2 > /mnt/quartz/usr/lib64/qt6/mkspecs/modules/qt_lib_gui_private.pri:QMAKE_INCDIR_HARFBUZZ = /mnt/quartz/usr/include/harfbuzz /mnt/quartz/usr/include/freetype2 /mnt/quartz/usr/include/glib-2.0 /mnt/quartz/usr/lib64/glib-2.0/include > /mnt/quartz/usr/lib64/qt6/mkspecs/modules/qt_lib_core_private.pri:QMAKE_INCDIR_GLIB = /mnt/quartz/usr/include/glib-2.0 /mnt/quartz/usr/lib64/glib-2.0/include > /mnt/quartz/usr/lib64/qt6/mkspecs/modules/qt_lib_core_private.pri:QMAKE_INCDIR_GOBJECT = /mnt/quartz/usr/include/glib-2.0 /mnt/quartz/usr/lib64/glib-2.0/include > /mnt/quartz/usr/lib64/qt6/mkspecs/modules/qt_lib_core_private.pri:QMAKE_INCDIR_GIO = /mnt/quartz/usr/include/glib-2.0 /mnt/quartz/usr/lib64/glib-2.0/include > /mnt/quartz/usr/lib64/qt6/mkspecs/modules/qt_lib_widgets_private.pri:QMAKE_INCDIR_GTK3 = /mnt/quartz/usr/include/gtk-3.0 /mnt/quartz/usr/include/pango-1.0 /mnt/quartz/usr/include/cairo /mnt/quartz/usr/include/gdk-pixbuf-2.0 /mnt/quartz/usr/include/atk-1.0 /mnt/quartz/usr/include/fribidi /mnt/quartz/usr/include/libpng16 /mnt/quartz/usr/include/pixman-1 /mnt/quartz/usr/include/harfbuzz /mnt/quartz/usr/include/freetype2 /mnt/quartz/usr/include/gio-unix-2.0 /mnt/quartz/usr/lib64/libffi/include /mnt/quartz/usr/include/glib-2.0 /mnt/quartz/usr/lib64/glib-2.0/include /mnt/quartz/usr/include/libmount /mnt/quartz/usr/include/blkid > /mnt/quartz/usr/lib64/qt6/mkspecs/qmodule.pri:QMAKE_INCDIR_DBUS = /mnt/quartz/usr/include/dbus-1.0 /mnt/quartz/usr/lib64/dbus-1.0/include I've traced this through to CMake "Find" modules in cmake/3rdparty that unfortunately do things like this: > # Use pkg-config to get the directories and then use these values > # in the FIND_PATH() and FIND_LIBRARY() calls > find_package(PkgConfig QUIET) > pkg_check_modules(PKG_Libinput QUIET libinput) > > set(Libinput_DEFINITIONS ${PKG_Libinput_CFLAGS_OTHER}) > set(Libinput_VERSION ${PKG_Libinput_VERSION}) > > find_path(Libinput_INCLUDE_DIR > NAMES > libinput.h > HINTS > ${PKG_Libinput_INCLUDE_DIRS} > ) > find_library(Libinput_LIBRARY > NAMES > input > HINTS > ${PKG_Libinput_LIBRARY_DIRS} > ) > > include(FindPackageHandleStandardArgs) > find_package_handle_standard_args(Libinput > FOUND_VAR > Libinput_FOUND > REQUIRED_VARS > Libinput_LIBRARY > Libinput_INCLUDE_DIR > VERSION_VAR > Libinput_VERSION > ) > > if(Libinput_FOUND AND NOT TARGET Libinput::Libinput) > add_library(Libinput::Libinput UNKNOWN IMPORTED) > set_target_properties(Libinput::Libinput PROPERTIES > IMPORTED_LOCATION "${Libinput_LIBRARY}" > INTERFACE_COMPILE_OPTIONS "${Libinput_DEFINITIONS}" > INTERFACE_INCLUDE_DIRECTORIES "${Libinput_INCLUDE_DIR}" > ) > endif() The CMake documentation advises you not to do this. It tells you what do instead, so I'll try that, but I'm not sure if it'll work here. https://cmake.org/cmake/help/latest/manual/cmake-packages.7.html#creating-relocatable-packages
