Summary: | dev-python/PyQt6-6.5.2 Project ERROR: Cannot run compiler 'g++'. Output: | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Meik Frischke <meik.frischke> |
Component: | Current packages | Assignee: | Ionen Wolkens <ionen> |
Status: | RESOLVED FIXED | ||
Severity: | normal | ||
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
See Also: |
https://bugs.gentoo.org/show_bug.cgi?id=908809 https://bugs.gentoo.org/show_bug.cgi?id=915695 |
||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Attachments: | build log |
Description
Meik Frischke
2023-09-02 11:47:11 UTC
Created attachment 869218 [details]
build log
What does the following two commands show? (assuming build dir exists) ls -l /var/tmp/portage/dev-python/PyQt6-6.5.2/temp/cxx /var/tmp/portage/dev-python/PyQt6-6.5.2/temp/cxx/g++ --version ls -l /var/tmp/portage/dev-python/PyQt6-6.5.2/temp/cxx total 0 lrwxrwxrwx 1 portage portage 48 Sep 2 13:14 clang++ -> /usr/lib/llvm/16/bin/x86_64-pc-linux-gnu-clang++ lrwxrwxrwx 1 portage portage 32 Sep 2 13:14 g++ -> /usr/bin/x86_64-pc-linux-gnu-g++ /var/tmp/portage/dev-python/PyQt6-6.5.2/temp/cxx/g++ --version g++ (Gentoo 12.3.1_p20230526 p2) 12.3.1 20230526 Copyright (C) 2022 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE That looks normal, strange. Anything special about your system? Like security features that may have potentially prevented the portage user (but not root) from executing that g++ through a symlink. Don't really have ideas beside that right now (can't reproduce). No, I have no special mount options, SELinux policies or anything else I can think of in place on that system. Portage can call the g++ symlink (tested with "su portage -s /bin/bash"). But your comment gave me the idea to try FEATURES="-sandbox -userpriv -usersandbox" for this build which completed successfully. So I'd call it a workaround but not solved. I doubt(?) sandbox/usersandbox would have an impact, but -userpriv would make it run as root, so it may indeed be a permission problem somewhere (qmake doesn't help by hiding errors). Maybe this could reveal something: namei -mo /var/tmp/portage/dev-python/PyQt6-6.5.2/temp/cxx/g++ For me it looks like: f: /var/tmp/portage/dev-python/PyQt6-6.5.2/temp/cxx/g++ drwxr-xr-x root root / drwxr-xr-x root root var drwxrwxrwt root root tmp drwxrwxr-x portage portage portage drwxrwxr-x portage portage dev-python drwx------ portage portage PyQt6-6.5.2 drwxr-xr-x portage portage temp drwxr-xr-x portage portage cxx lrwxrwxrwx portage portage g++ -> /usr/bin/x86_64-pc-linux-gnu-g++ drwxr-xr-x root root / drwxr-xr-x root root usr drwxr-xr-x root root bin lrwxrwxrwx root root x86_64-pc-linux-gnu-g++ -> /usr/x86_64-pc-linux-gnu/gcc-bin/13/x86_64-pc-linux-gnu-g++ drwxr-xr-x root root / drwxr-xr-x root root usr drwxr-xr-x root root x86_64-pc-linux-gnu drwxr-xr-x root root gcc-bin drwxr-xr-x root root 13 -rwxr-xr-x root root x86_64-pc-linux-gnu-g++ Then again if portage user was able to run it I guess this wouldn't add up. namei looks identical (with 12 instead of 13 on your system): f: /var/tmp/portage/dev-python/PyQt6-6.5.2/temp/cxx/g++ drwxr-xr-x root root / drwxr-xr-x root root var drwxrwxrwt root root tmp drwxrwxr-x portage portage portage drwxrwxr-x portage portage dev-python drwx------ portage portage PyQt6-6.5.2 drwxr-xr-x portage portage temp drwxr-xr-x portage portage cxx lrwxrwxrwx portage portage g++ -> /usr/bin/x86_64-pc-linux-gnu-g++ drwxr-xr-x root root / drwxr-xr-x root root usr drwxr-xr-x root root bin lrwxrwxrwx root root x86_64-pc-linux-gnu-g++ -> /usr/x86_64-pc-linux-gnu/gcc-bin/12/x86_64-pc-linux-gnu-g++ drwxr-xr-x root root / drwxr-xr-x root root usr drwxr-xr-x root root x86_64-pc-linux-gnu drwxr-xr-x root root gcc-bin drwxr-xr-x root root 12 -rwxr-xr-x root root x86_64-pc-linux-gnu-g++ Well, still no idea. I could change the handling a bit but, without knowing why it happens, it does not amount to much. I'll leave this open for now and see if anyone else is affected. Hm, I thought it was the symlink (somehow) but I was looking at qt-related bugs and looks awfully like bug #908809 (which is also due to sandbox). This may just be a general qmake6+sandbox issue, not that I've run into that myself. The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=9152c25f592db19e2d6f6ab0aab991a463503a34 commit 9152c25f592db19e2d6f6ab0aab991a463503a34 Author: Ionen Wolkens <ionen@gentoo.org> AuthorDate: 2023-10-21 05:46:22 +0000 Commit: Ionen Wolkens <ionen@gentoo.org> CommitDate: 2023-10-21 06:21:50 +0000 dev-qt/qtbase: fix qsb and qmake with sandbox Also add to 6.5.3, while the issue has been less prominent in 6.5.x, there has been users that ran into issues with older versions, and is needed for stable users. See bug #915695 for details, the others are essentially duplicates which are hopefully fixed too (please report if still issues given I could never reproduce myself and cannot confirm). Closes: https://bugs.gentoo.org/908809 Closes: https://bugs.gentoo.org/908816 Closes: https://bugs.gentoo.org/913493 Closes: https://bugs.gentoo.org/915695 Thanks-to: vowstar Thanks-to: Mike Gilbert <floppym@gentoo.org> Signed-off-by: Ionen Wolkens <ionen@gentoo.org> .../qtbase-6.5.3-forkfd-childstack-size.patch | 27 ++++++++++++++++++++++ ...{qtbase-6.5.3.ebuild => qtbase-6.5.3-r1.ebuild} | 1 + ...{qtbase-6.6.0.ebuild => qtbase-6.6.0-r1.ebuild} | 1 + 3 files changed, 29 insertions(+) |