dev-qt/qtbase-6.8.2-r2 is such that once any package while building against it executes the target's toolchain binaries instead of the build host's toolchain's binary. Attached is the failed build log of kquickcharts-6.10.0 while cross compiling. The toolchain requires qtpaths which is executed as follows -- Incompatible processor. This Qt build requires the following features: waitpkg gfni vaes CMake Warning at /usr/share/ECM/modules/ECMQueryQt.cmake:95 (message): Failed call: /usr/x86_64-mypc-linux-gnu/usr/lib64/qt6/bin/qtpaths --query The toolchain must execute /usr/lib64/qt6/bin/qtpaths instead of /usr/x86_64-mypc-linux-gnu/usr/lib64/qt6/bin/qtpaths. /usr/x86_64-mypc-linux-gnu/ is a foreign system maintained by crossdev which is incompatible with the build host. Attached is another failed build log of kuserfeedback-6.10.0 with similar problems -- /usr/x86_64-mypc-linux-gnu/usr/lib64/qt6/bin/lrelease -removeidentical -nounfinished -silent /tmp/portage/kde-frameworks/kuserfeedback-6.10.0/work/kuserfeedback-6.10.0_build/ECMPoQm/bg/userfeedbackconsole6_qt.ts -qm /tmp/portage/kde-frameworks/kuserfeedback-6.10.0/work/kuserfeedback-6.10.0_build/ECMPoQm/bg/userfeedbackconsole6_qt.qm Incompatible processor. This Qt build requires the following features: waitpkg gfni vaes Note the /usr/x86_64-mypc-linux-gnu/ prefix of lrelease. Removing the following block from dev-qt/qtbase-6.8.2-r2's ebuild (introduced with qtbase-6.8.2-r2) -- tc-is-cross-compiler && mycmakeargs+=( and rebuilding qtbase along with all dev-qt/* packages resolve the issue.
Created attachment 919936 [details] kuserfeedback failed build log with qtbase-6.8.2-r2
Created attachment 919937 [details] kquickcharts failed build log with qtbase-6.8.2-r2
I'm a bit surprised by that. We have seen some leakage of the SYSROOT, but this is in qmake-specific files, nothing that CMake would touch. I'll look into it though.
I haven't been able to reproduce this with either package, at least when using cross-boss. I'll take another look soon.
In CMakeCache.txt there is -- Qt6CoreTools_DIR:PATH=/usr/x86_64-mypc-linux-gnu/usr/lib64/cmake/Qt6CoreTools Qt6_DIR:PATH=/usr/x86_64-mypc-linux-gnu/usr/lib64/cmake/Qt6 cb-emerge results in the same error.
Note that dE been known to set some *ROOT variable (I forgot what exactly) themselves and it may not be a normal cross setup if can't reproduce.
(In reply to Ionen Wolkens from comment #6) > Note that dE been known to set some *ROOT variable (I forgot what exactly) > themselves and it may not be a normal cross setup if can't reproduce. This is plane crossdev. It automatically uses those variables. earlier I was using emerge with those variables set manually.
The difference is that this installation was migrated from a 'real' gentoo install. But this was done a long time back. Multiple upgrades have been commenced since then.
I didn't expect it, but I've managed to reproduce this with plain crossdev.
It's something to do with these differences: > -CMake Debug Log at /usr/aarch64-unknown-linux-gnu/usr/lib64/cmake/Qt6/Qt6Config.cmake:200 (find_package): > +CMake Debug Log at /mnt/quartz/usr/lib64/cmake/Qt6/Qt6Config.cmake:200 (find_package): > The internally managed CMAKE_FIND_PACKAGE_REDIRECTS_DIR. > > /var/tmp/portage/kde-frameworks/kuserfeedback-6.11.0/work/kuserfeedback-6.11.0_build/CMakeFiles/pkgRedirects > @@ -1094,7 +1094,7 @@ > > Paths specified by the find_package PATHS option. > > - /usr/aarch64-unknown-linux-gnu/usr/lib64/cmake > + /mnt/quartz/usr/lib64/cmake > /usr/lib64/cmake > > Prepending the following roots to each prefix: > @@ -1113,18 +1113,18 @@ > > CMAKE_SYSROOT > > - /usr/aarch64-unknown-linux-gnu > + /mnt/quartz > > find_package considered the following locations for Qt6CoreTools's Config > module: > > - /usr/aarch64-unknown-linux-gnu/usr/lib64/cmake/Qt6CoreToolsConfig.cmake > - /usr/aarch64-unknown-linux-gnu/usr/lib64/cmake/qt6coretools-config.cmake > - /usr/aarch64-unknown-linux-gnu/usr/lib64/cmake/Qt6CoreTools/Qt6CoreToolsConfig.cmake > + /usr/lib64/cmake/Qt6CoreToolsConfig.cmake > + /usr/lib64/cmake/qt6coretools-config.cmake > + /usr/lib64/cmake/Qt6CoreTools/Qt6CoreToolsConfig.cmake > > The file was found at > > - /usr/aarch64-unknown-linux-gnu/usr/lib64/cmake/Qt6CoreTools/Qt6CoreToolsConfig.cmake > + /usr/lib64/cmake/Qt6CoreTools/Qt6CoreToolsConfig.cmake Notice how find_package "considers" /usr/aarch64-unknown-linux-gnu in the broken case but / in the working case. I just don't know why! Everything else I can see is the same.
Hah! It's because /usr/aarch64-unknown-linux-gnu is under /usr. If I bind mount /mnt/quartz to /usr/quartz and build against that, it fails in the same way! Now what to do about that...
Adding "set(CMAKE_FIND_ROOT_PATH_MODE_PACKAGE NEVER)" to the toolchain file gets it past that point, but then it fails later. Even if it worked, I don't think we want to do that.
Appending /lib64 to this path in /usr/aarch64-unknown-linux-gnu/usr/lib64/cmake/Qt6/Qt6Config.cmake "fixes" it. Perhaps there's a better way. > list(PREPEND CMAKE_FIND_ROOT_PATH "${QT_HOST_PATH}/lib64" > ${_qt_additional_host_packages_root_paths})
Proposed fix on the way, just testing it out.
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=34215c570dac0cf122f3d0e54209f061c5d6264f commit 34215c570dac0cf122f3d0e54209f061c5d6264f Author: James Le Cuirot <chewi@gentoo.org> AuthorDate: 2025-03-02 22:42:38 +0000 Commit: James Le Cuirot <chewi@gentoo.org> CommitDate: 2025-03-03 22:38:19 +0000 dev-qt/qtbase: Patch Qt6Config.cmake to fix cross-compiling other packages It's a long story involving CMAKE_FIND_ROOT_PATH. See the patch for details. Closes: https://bugs.gentoo.org/950314 Closes: https://github.com/gentoo/gentoo/pull/40856 Signed-off-by: James Le Cuirot <chewi@gentoo.org> dev-qt/qtbase/files/qtbase-6.8.2-cross.patch | 36 ++++++++++++++++++++++++++++ dev-qt/qtbase/qtbase-6.8.2-r2.ebuild | 1 + dev-qt/qtbase/qtbase-6.8.9999.ebuild | 1 + dev-qt/qtbase/qtbase-6.9.9999.ebuild | 1 + dev-qt/qtbase/qtbase-6.9999.ebuild | 1 + 5 files changed, 40 insertions(+)
