Created attachment 780746 [details, diff] CMakeLists.txt patch for CCACHE_ALLOWED option Quick-fix to allow for turning off ccache in stellarium's CMakeLists.txt Building stellarium versions 0.21.3 as well as 0.22.1 yields numerous sandbox violations when it detects ccache to be available on the system. This is exactly the same thing going wrong as in e.g. bug 841518 Again, it needs a two-part fix: -DCCACHE_ALLOWED="OFF" in mycmakeargs, and a patch to the top-level CMakeLists.txt to short-circuit the opportunistic check for a ccache binary. I am starting to wonder if there's something else going on, and/or there could/should be a more generic solution to this type of issue.
Created attachment 780749 [details, diff] ebuild patch to pull in the CMakeLists.txt patch
To clarify: I would actually want to use ccache and have it enabled in FEATURES, but because of how these CMakeLists.txt try to detect ccache, it doesn't work with portage. My reading/guess is that the (non-portage) "variant" of ccache that gets picked up is not correctly configured for use with/in the sandbox. Conversely, with this patch, ccache is simply not used at all. Does anyone have appropriate portage and CMake knowledge what would need to be fulfilled for CMake to correctly use the portage-provided ccache?
(In reply to Joe Breuer from comment #2) > To clarify: I would actually want to use ccache and have it enabled in > FEATURES, but because of how these CMakeLists.txt try to detect ccache, it > doesn't work with portage. My reading/guess is that the (non-portage) > "variant" of ccache that gets picked up is not correctly configured for use > with/in the sandbox. > > Conversely, with this patch, ccache is simply not used at all. > > Does anyone have appropriate portage and CMake knowledge what would need to > be fulfilled for CMake to correctly use the portage-provided ccache? It should simply respect the compiler options set by the environment and not try to bypass by looking for "the real" compiler if the ccache option to CMake is disabled. So, remove all the magic. Not checked what's happening here but this kind of approach seems somewhat common sadly :(
Reading what https://cmake.org/cmake/help/latest/prop_gbl/RULE_LAUNCH_COMPILE.html does, I believe this should be fixed more centrally, in cmake.eclass, similarly to how it already comments out hardcoded changes to CMAKE_INSTALL_PREFIX
I'm not sure it is worth it, packages have all kinds of ways to check for ccache then use it, there is no standard switch I know of?
(In reply to Andreas Sturmlechner from comment #5) > I'm not sure it is worth it, packages have all kinds of ways to check for > ccache then use it, there is no standard switch I know of? I understand there to be two different issues: CMake looking for ccache seems to be a per-package thing, and probably needs to be patched out per-package (or the sandbox can learn to "hide" ccache... hmm.). On the other hand, looking for a "real" compiler (bypassing ccache, distcc, ... whatever may be set up for/by portage) apparently is "standard" CMake functionality, which could be bypassed centrally. I'll have a stab at this later / over the next couple of days.
> looking for ccache seems to be a per-package thing, and probably needs to be patched out per-package This is true. I hoped special generic handling of RULE_LAUNCH_COMPILE would help, but apparently no. > looking for a "real" compiler (bypassing ccache, distcc, ... whatever may be set up for/by portage) apparently is "standard" CMake functionality, which could be bypassed centrally. CMake doesn't bypass anything. It uses CC/CXX env variables and CMAKE_C_COMPILER etc cmake variables and therefore searches for x86_64-pc-linux-gnu-g++ in PATH, so ends up using /usr/lib/ccache/bin/x86_64-pc-linux-gnu-g++, because FEATURES=ccache adds that dir to PATH. The whole /usr/lib/ccache/bin/ directory is full of symlinks to /usr/bin/ccache. If in your case ccache doesn't get picked up, paste build log, and show what's in that directory.
(In reply to Alexey from comment #7) > > looking for ccache seems to be a per-package thing, and probably needs to be patched out per-package > > This is true. I hoped special generic handling of RULE_LAUNCH_COMPILE would > help, but apparently no. > > > looking for a "real" compiler (bypassing ccache, distcc, ... whatever may be set up for/by portage) apparently is "standard" CMake functionality, which could be bypassed centrally. > > CMake doesn't bypass anything. It uses CC/CXX env variables and > CMAKE_C_COMPILER etc cmake variables and therefore searches for > x86_64-pc-linux-gnu-g++ in PATH, so ends up using > /usr/lib/ccache/bin/x86_64-pc-linux-gnu-g++, because FEATURES=ccache adds > that dir to PATH. The whole /usr/lib/ccache/bin/ directory is full of > symlinks to /usr/bin/ccache. > > If in your case ccache doesn't get picked up, paste build log, and show > what's in that directory. It shouldn't do a PATH lookup, it's unnecessary.
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=d32c1aac166b5914ac2feb6d5abf008442220026 commit d32c1aac166b5914ac2feb6d5abf008442220026 Author: Alexey Sokolov <alexey+gentoo@asokolov.org> AuthorDate: 2022-07-10 09:24:00 +0000 Commit: Florian Schmaus <flow@gentoo.org> CommitDate: 2022-07-19 07:36:24 +0000 sci-astronomy/stellarium: version 0.22.2 Closes: https://bugs.gentoo.org/847439 Package-Manager: Portage-3.0.30, Repoman-3.0.3 Signed-off-by: Alexey Sokolov <alexey+gentoo@asokolov.org> Closes: https://github.com/gentoo/gentoo/pull/26323 Signed-off-by: Florian Schmaus <flow@gentoo.org> sci-astronomy/stellarium/Manifest | 3 + .../files/stellarium-0.22.2-ccache.patch | 13 ++ .../stellarium-0.22.2-unbundle-qtcompress.patch | 208 +++++++++++++++++++++ sci-astronomy/stellarium/stellarium-0.22.2.ebuild | 144 ++++++++++++++ 4 files changed, 368 insertions(+)
