libksysguard 6.3.0 fails to build when using the LLVM profile because it now uses std::jthread and std::stop_token that llvm's libc++ considers experimental and does not build by default. This change introduced their usage to libksysguard: https://invent.kde.org/plasma/libksysguard/-/merge_requests/382 Those features will be enabled by default in libc++ 20, but it is not released yet (see https://github.com/llvm/llvm-project/pull/107900). The exact error is: In file included from /var/tmp/portage/kde-plasma/libksysguard-6.3.0/work/libksysguard-6.3.0/processcore/processes_local_p.cpp:8: /var/tmp/portage/kde-plasma/libksysguard-6.3.0/work/libksysguard-6.3.0/processcore/processes_linux_p.cpp:121:42: error: no type named 'stop_token' in namespace 'std' 121 | static void smapsThreadFunction(std::stop_token stopToken, ProcessesLocal *processes); | ~~~~~^ /var/tmp/portage/kde-plasma/libksysguard-6.3.0/work/libksysguard-6.3.0/processcore/processes_linux_p.cpp:127:21: error: no member named 'jthread' in namespace 'std'; did you mean 'pread'? 127 | std::unique_ptr<std::jthread> smapsThread = nullptr; | ^~~~~~~~~~~~ | pread /usr/include/bits/unistd.h:40:1: note: 'pread' declared here 40 | pread (int __fd, __fortify_clang_overload_arg0 (void *, ,__buf), | ^ In file included from /var/tmp/portage/kde-plasma/libksysguard-6.3.0/work/libksysguard-6.3.0/processcore/processes_local_p.cpp:8: /var/tmp/portage/kde-plasma/libksysguard-6.3.0/work/libksysguard-6.3.0/processcore/processes_linux_p.cpp:127:26: error: template argument for template type parameter must be a type 127 | std::unique_ptr<std::jthread> smapsThread = nullptr; | ^~~~~~~ /usr/include/c++/v1/__memory/unique_ptr.h:137:17: note: template parameter is declared here 137 | template <class _Tp, class _Dp = default_delete<_Tp> > | ^ In file included from /var/tmp/portage/kde-plasma/libksysguard-6.3.0/work/libksysguard-6.3.0/processcore/processes_local_p.cpp:8: /var/tmp/portage/kde-plasma/libksysguard-6.3.0/work/libksysguard-6.3.0/processcore/processes_linux_p.cpp:141:56: error: no type named 'stop_token' in namespace 'std' 141 | void ProcessesLocal::Private::smapsThreadFunction(std::stop_token stopToken, ProcessesLocal *processes) | ~~~~~^ /var/tmp/portage/kde-plasma/libksysguard-6.3.0/work/libksysguard-6.3.0/processcore/processes_linux_p.cpp:664:47: error: no member named 'jthread' in namespace 'std'; did you mean 'pread'? 664 | d->smapsThread = std::make_unique<std::jthread>(Private::smapsThreadFunction, this); | ^~~~~~~~~~~~ | pread /usr/include/bits/unistd.h:40:1: note: 'pread' declared here 40 | pread (int __fd, __fortify_clang_overload_arg0 (void *, ,__buf), | ^ In file included from /var/tmp/portage/kde-plasma/libksysguard-6.3.0/work/libksysguard-6.3.0/processcore/processes_local_p.cpp:8: /var/tmp/portage/kde-plasma/libksysguard-6.3.0/work/libksysguard-6.3.0/processcore/processes_linux_p.cpp:664:70: error: call to non-static member function without an object argument 664 | d->smapsThread = std::make_unique<std::jthread>(Private::smapsThreadFunction, this); | ~~~~~~~~~^~~~~~~~~~~~~~~~~~~ 6 errors generated.
Adding "-fexperimental-library" to CFLAGS/CXXFLAGS fixes this for me and libksysguard built successfully.
I'm not really interested in that. Those who want to build with llvm need to take it up with upstream.
(In reply to Robert Holt from comment #1) > Adding "-fexperimental-library" to CFLAGS/CXXFLAGS fixes this for me and > libksysguard built successfully. Adding -fexperimental-library to CXXFLAGS resolved the issue for me. Thank you. (In reply to Andreas Sturmlechner from comment #2) > I'm not really interested in that. Those who want to build with llvm need to > take it up with upstream. If the LLVM profile is officially available through Gentoo why have this kind of attitude? Is it too much to ask for a CC check in the ebuild and add the flag until it's officially supported? Upstream KDE is likely to tell us to take it to LLVM, and LLVM has already merged support for version 20. Not sure what more you want.
(In reply to unhappy-ending from comment #3) The profiles are marked as experimental. Bug reports for them are expected to come with patches / pull requests. asturm's message is an indication that he won't work on it, he's not closing it as WONTFIX, he's just being clear that he's not going to be spending time on it, so others need to.
No, he said he has not interest, upstream should address it. As unhappy-ending said, it is upstream, so for the time beeing until Clang 20 is available, libksysguard has to be patched: --- a/kde-plasma/libksysguard/libksysguard-6.3.0.ebuild 2025-02-12 09:58:31.135408739 +0100 +++ b/kde-plasma/libksysguard/libksysguard-6.3.0.ebuild 2025-02-14 10:54:07.964561219 +0100 @@ -39,6 +39,12 @@ FILECAPS=( -m 0755 cap_sys_nice=ep usr/libexec/ksysguard/ksgrd_network_helper ) src_configure() { + # support std::jthread and std::stop_token is not enabled per default + # in libc++ prior to version 20, need to add "-fexperimental-library" + if tc-is-clang && [[ "$(clang-major-version)" -lt 20 ]]; then + append-cxxflags "-fexperimental-library" + fi + local mycmakeargs=( -DCMAKE_DISABLE_FIND_PACKAGE_Libcap=ON ) Another way if devs still are unwilling is to use package.env.
I have added a check if libc++ is used per default in clang. I'm not a Gentoo dev so I don't know if there is another way to check wether clang is configured to use libc++ instead of libstdc++. --- a/kde-plasma/libksysguard/libksysguard-6.3.0.ebuild 2025-02-12 09:58:31.135408739 +0100 +++ b/kde-plasma/libksysguard/libksysguard-6.3.0.ebuild 2025-02-14 10:54:07.964561219 +0100 @@ -39,6 +39,12 @@ FILECAPS=( -m 0755 cap_sys_nice=ep usr/libexec/ksysguard/ksgrd_network_helper ) src_configure() { + # support std::jthread and std::stop_token is not enabled per default + # in libc++ prior to version 20, need to add "-fexperimental-library" + if tc-is-clang && has_vesion llvm-core/clang-runtime[libcxx] && [[ "$(clang-major-version)" -lt 20 ]]; then + append-cxxflags "-fexperimental-library" + fi + local mycmakeargs=( -DCMAKE_DISABLE_FIND_PACKAGE_Libcap=ON )
(In reply to Steffen Hau from comment #5) > No, he said he has not interest, upstream should address it. As > unhappy-ending said, it is upstream, so for the time beeing until Clang 20 > is available, libksysguard has to be patched: I speak asturm and I know what he means. It's not always easy to know if a bug report is a bug report for the benefit of other users doing something advanced, or if they're seeking help instead (in which case it's often useful to say that no help is going to be forthcoming from us if that's the case). > > --- a/kde-plasma/libksysguard/libksysguard-6.3.0.ebuild 2025-02-12 > 09:58:31.135408739 +0100 > +++ b/kde-plasma/libksysguard/libksysguard-6.3.0.ebuild 2025-02-14 > 10:54:07.964561219 +0100 > @@ -39,6 +39,12 @@ > FILECAPS=( -m 0755 cap_sys_nice=ep > usr/libexec/ksysguard/ksgrd_network_helper ) > > src_configure() { > + # support std::jthread and std::stop_token is not enabled per default > + # in libc++ prior to version 20, need to add "-fexperimental-library" > + if tc-is-clang && [[ "$(clang-major-version)" -lt 20 ]]; then > + append-cxxflags "-fexperimental-library" > + fi > + > local mycmakeargs=( > -DCMAKE_DISABLE_FIND_PACKAGE_Libcap=ON > ) > > Another way if devs still are unwilling is to use package.env. Perhaps I was too subtle earlier: I'll happily merge PRs for this stuff, I'm not going to spend time on it otherwise.
(In reply to Steffen Hau from comment #6) > I have added a check if libc++ is used per default in clang. I'm not a > Gentoo dev so I don't know if there is another way to check wether clang is > configured to use libc++ instead of libstdc++. Please use tc-get-cxx-stdlib. I think there's an example already in a KDE package somewhere too.
Thanks for the hint, I have added it. I hope this is now good enough to land in the ebuild. --- a/kde-plasma/libksysguard/libksysguard-6.3.0.ebuild 2025-02-12 09:58:31.135408739 +0100 +++ b/kde-plasma/libksysguard/libksysguard-6.3.0.ebuild 2025-02-14 11:15:51.205312101 +0100 @@ -39,6 +39,12 @@ FILECAPS=( -m 0755 cap_sys_nice=ep usr/libexec/ksysguard/ksgrd_network_helper ) src_configure() { + # support std::jthread and std::stop_token is not enabled per default + # in libc++ prior to version 20, need to add "-fexperimental-library" + if tc-is-clang && [[ $(tc-get-cxx-stdlib) == libc++ ]] && [[ "$(clang-major-version)" -lt 20 ]]; then + append-cxxflags "-fexperimental-library" + fi + local mycmakeargs=( -DCMAKE_DISABLE_FIND_PACKAGE_Libcap=ON )
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=323cafda278f34bd4957affc1580c150e5a28a5a commit 323cafda278f34bd4957affc1580c150e5a28a5a Author: Sam James <sam@gentoo.org> AuthorDate: 2025-02-14 10:36:30 +0000 Commit: Sam James <sam@gentoo.org> CommitDate: 2025-02-14 10:36:30 +0000 kde-plasma/libksysguard: fix build w/ <libcxx-20 Per Robert on the bug: > libksysguard 6.3.0 fails to build when using the LLVM profile because it now uses > std::jthread and std::stop_token that llvm's libc++ considers experimental > and does not build by default. They're unleashed in libcxx 20 which should be released shortly. In the meantime, pass -fexperimental-library. Closes: https://bugs.gentoo.org/949636 Thanks-to: Steffen Hau <steffen@hauihau.de> Thanks-to: Robert Holt <holt.r94@gmail.com> Signed-off-by: Sam James <sam@gentoo.org> kde-plasma/libksysguard/libksysguard-6.3.0.ebuild | 8 +++++++- 1 file changed, 7 insertions(+), 1 deletion(-)
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/proj/kde.git/commit/?id=792be1a00ab69ae88089144481b8bdd0fefbf6a1 commit 792be1a00ab69ae88089144481b8bdd0fefbf6a1 Author: Sam James <sam@gentoo.org> AuthorDate: 2025-02-14 10:36:30 +0000 Commit: Sam James <sam@gentoo.org> CommitDate: 2025-02-14 10:40:11 +0000 kde-plasma/libksysguard: fix build w/ <libcxx-20 Per Robert on the bug: > libksysguard 9999 fails to build when using the LLVM profile because it now uses > std::jthread and std::stop_token that llvm's libc++ considers experimental > and does not build by default. They're unleashed in libcxx 20 which should be released shortly. In the meantime, pass -fexperimental-library. Closes: https://bugs.gentoo.org/949636 Thanks-to: Steffen Hau <steffen@hauihau.de> Thanks-to: Robert Holt <holt.r94@gmail.com> Signed-off-by: Sam James <sam@gentoo.org> kde-plasma/libksysguard/libksysguard-6.3.49.9999.ebuild | 8 +++++++- kde-plasma/libksysguard/libksysguard-9999.ebuild | 8 +++++++- 2 files changed, 14 insertions(+), 2 deletions(-)
Thanks. In future, please consider attaching `git am`-able patches (via `git format-patch`) or making a github PR. That way, it's easy to get attribution right, and it's very hard for me to be lazy and say no ;)
I will. Do you have a quick and dirty howto in howto PR patches without forking gentoo/gentoo? I dod not work in a git directory, hence it was just a plain diff.
