It fails early on: CMake Error at CMakeLists.txt:58 (message): The path "/tmp/portage/dev-qt/qtbase-6.5.2-r2/work/qtbase-everywhere-src-6.5.2_build" contains symlinks. This is not supported. Possible solutions: - Map directories using a transparent mechanism such as mount --bind - Pass the real path of the build directory to CMake, e.g. using cd $(realpath <path>) before invoking cmake <source_dir>. Call Stack (most recent call first): CMakeLists.txt:65 (qt_internal_check_if_path_has_symlinks) Reproducible: Always Indeed /tmp is a symlink (to var/tmp, on a real, spinning, disk, / is a ssd). This is a fairly common setup on lot of desktop/servers i administer. I never had any problem with this. Does gentoo has a position on this ? I know about mount -bind, but that's more complicated because the link is not 'obvious' when using ls.
Wonder why it even pickups /tmp? * Source directory (CMAKE_USE_DIR): "/var/tmp/portage/dev-qt/qtbase-6.5.2-r2/work/qtbase-everywhere-src-6.5.2" * Build directory (BUILD_DIR): "/var/tmp/portage/dev-qt/qtbase-6.5.2-r2/work/qtbase-everywhere-src-6.5.2_build" (note /var/tmp) CMake Error at CMakeLists.txt:58 (message): The path "/tmp/portage/dev-qt/qtbase-6.5.2-r2/work/qtbase-everywhere-src-6.5.2_build"
aka I was about to say just don't use PORTAGE_TMPDIR=/tmp and use the real path, but then it seems there's some nonsense going on and I do assume you're using /var/tmp.
ah, indeed, /var/tmp is mentionned. I don't know then. I can confirm i have PORTAGE_TMPDIR=/var/tmp in make.conf.
the problem comes from ../work/qtbase-everywhere-src-6.5.2/CMakeLists.txt And there, CMAKE_BINARY_DIR is indeed /tmp/ instead of /var/tmp. But I dont know where this variable comes from, presumably from cmake... I don't know how to debug further.
Yeah, being picky about symlinks in the build dir does not seem so great on itself, but that is something else. Could possibly be a odd quirk in cmake itself, or at most the eclass (haven't had a close look).
It does work fine with e.g. PORTAGE_TMPDIR=/otherdir. "Maybe" cmake is doing something strange like trying to shorten the path, aka it finds that /tmp/dir is the same inode as /var/tmp/dir or something, then strips /var If so, then I don't really know what to do with this.
(In reply to Ionen Wolkens from comment #6) > It does work fine with e.g. PORTAGE_TMPDIR=/otherdir. > > "Maybe" cmake is doing something strange like trying to shorten the path, > aka it finds that /tmp/dir is the same inode as /var/tmp/dir or something, > then strips /var > > If so, then I don't really know what to do with this. (possibly intended to simplify e.g. /dir/dir/../../dir cases)
As far as qtbase goes, this was added by [1], not that the behaviour described in [2] should affect us. There's a 2nd bug, but it's either restricted or deleted, so I don't know what it was about. Either way, dropping the symlink check seems harmless so may just do that after a closer look. If someone feels like convincing upstream that the check is not needed it'd be great, albeit ball risks being tossed around when it's partly caused by cmake passing a different path than the real symlink-less one we gave to it. [1] https://github.com/qt/qtbase/commit/41aff1cd938457539fd6fd1009a3859de6b78095 [2] https://bugreports.qt.io/browse/QTBUG-89559
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=4d490887059ff73ebd7ad9d76348c001d02c5ef5 commit 4d490887059ff73ebd7ad9d76348c001d02c5ef5 Author: Ionen Wolkens <ionen@gentoo.org> AuthorDate: 2023-09-14 20:08:52 +0000 Commit: Ionen Wolkens <ionen@gentoo.org> CommitDate: 2023-09-14 20:14:09 +0000 dev-qt/qtbase: skip build dir's symlink check Closes: https://bugs.gentoo.org/914195 Signed-off-by: Ionen Wolkens <ionen@gentoo.org> dev-qt/qtbase/files/qtbase-6.5.2-no-symlink-check.patch | 5 +++++ dev-qt/qtbase/qtbase-6.5.2-r2.ebuild | 1 + dev-qt/qtbase/qtbase-6.5.9999.ebuild | 4 ++++ dev-qt/qtbase/qtbase-6.6.9999.ebuild | 4 ++++ dev-qt/qtbase/qtbase-6.9999.ebuild | 4 ++++ 5 files changed, 18 insertions(+)
I tried this last version and I can confirm it now works, thanks !
