Bug 923292 – kde-plasma/layer-shell-qt:6 built with clang/libc++: plasmashell crashes when right clicking on a panel or desktop w/ layershellqt: Cannot attach popup of unknown type

• Status: IN_PROGRESS
• Product: Gentoo Linux

[Description Michael Egger 2024-01-29 20:03:17 UTC]

Right clicking anywhere on the plasmashell panel or desktop results in crashing plasmashell.
There exists an upstream bug report, but it seems it's a packaging issue: https://bugs.kde.org/show_bug.cgi?id=479679


How to reproduce:
Start a plasma session and right click anywhere on a panel or the desktop.

Expected behavior:
A popup opens

Actual behavior:
Plasmashell crashes and restarts


SOFTWARE/OS VERSIONS
Linux/KDE Plasma: Gentoo 2.14/5.92.0
(available in About System)
KDE Plasma Version: 5.92.0
KDE Frameworks Version: 5.248.0
Qt Version: 6.6.1
Graphics Platform: Wayland


Relevant logs:
Jan 26 11:45:16 gentoo3 kwin_wayland_wrapper[1419]: error in client communication (pid 3515)
Jan 26 11:45:16 gentoo3 plasmashell[3515]: xdg_wm_base@3: error 3: no xdg_popup parent surface has been specified
Jan 26 11:45:16 gentoo3 systemd[1276]: plasma-plasmashell.service: Main process exited, code=exited, status=255/EXCEPTION
Jan 26 11:45:16 gentoo3 systemd[1276]: plasma-plasmashell.service: Failed with result 'exit-code'.
Jan 26 11:45:16 gentoo3 systemd[1276]: plasma-plasmashell.service: Consumed 2.103s CPU time.
Jan 26 11:45:16 gentoo3 systemd[1276]: plasma-plasmashell.service: Scheduled restart job, restart counter is at 2.
Jan 26 11:45:16 gentoo3 systemd[1276]: Starting KDE Plasma Workspace...
Jan 26 11:45:16 gentoo3 systemd[1276]: Started KDE Plasma Workspace.

[Comment 1 Andreas Sturmlechner 2024-01-29 20:07:06 UTC]

Please report to upstream.

[Comment 2 Michael Egger 2024-01-29 20:12:01 UTC]

The issue has been reported upstream https://bugs.kde.org/show_bug.cgi?id=479679, but cannot be reproduced and seems to be a gentoo packaging issue:

> Cannot reproduce either with built-from-source Plasma on top of Fedora 39.
> I strongly suspect this is a packaging issue.
> Maybe the layershell protocol definition is out of date?
> Either way please follow up with Gentoo folks about it. Thanks!

[Comment 3 Andreas Sturmlechner 2024-01-29 20:20:27 UTC]

Please add emerge --info, as always in Gentoo bugs.

In case you have added kde overlay at all, please make sure *all* kde-frameworks and kde-plasma packages are consistently at version 5.248.0 and 5.92.0 respectively, no mix with -9999.

[Comment 4 Andreas Sturmlechner 2024-01-29 20:21:33 UTC]

Do you apply any kind of user patches on top of Qt/Frameworks/Plasma?

[Comment 5 Michael Egger 2024-01-29 20:32:08 UTC]

> Do you apply any kind of user patches on top of Qt/Frameworks/Plasma?
There are no custom patches applied


> In case you have added kde overlay at all, please make sure *all* kde-frameworks and kde-plasma packages are consistently at version 5.248.0 and 5.92.0 respectively, no mix with -9999.
The kde overlay is active but the only thing unmasked is kde-gear-24.02. No -9999 packages are in use for QT/frameworks/plasma/gears:

gentoo3 /etc/portage/package.unmask # ls -la
total 8
drwxr-xr-x 1 root root  56 Jan 24 16:17 .
drwxr-xr-x 1 root root 360 Dec 14 14:10 ..
-rw-r--r-- 1 root root   0 Dec 22 15:52 common
lrwxrwxrwx 1 root root  61 Jan 24 16:17 kde-gear-24.02 -> /var/db/repos/kde/Documentation/package.unmask/kde-gear-24.02

[Comment 6 Michael Egger 2024-01-29 20:32:35 UTC]

Created attachment 883644 [details]
emerge info

[Comment 7 Andreas Sturmlechner 2024-01-29 20:34:16 UTC]

Maybe you can try without -O3 and lto?

[Comment 8 Andreas Sturmlechner 2024-02-12 18:23:18 UTC]

Reassigning this to llvm as I think it may be out of scope for kde proj.

[12:40] <DavidRedondo> fvogt
[12:40] <DavidRedondo> if I compile this program with clang++
[12:40] * DavidRedondo sent a code block:
>         #include <any>
>         #include <dlfcn.h>
> 
>         struct xdg_popup;
> 
>         #ifdef IS_PLUGIN
> 
>         std::any get_any() 
>         {
>             return (xdg_popup*)0xf00;
>         }
> 
>         #else
> 
>         int main()
>         {
>             auto plugin = dlopen("./plugin.so", RTLD_LAZY | RTLD_NODELETE);
>             auto get_any =  reinterpret_cast<std::any(*)()>(dlsym(plugin, "_Z7get_anyv"));
>             std::any_cast<xdg_popup*>(get_any());
>         }
> 
>         #endif
[12:40] <DavidRedondo> I get bad_any_cast with libc++ but it works fine with libstdc+++
[12:41] <DavidRedondo> RTLD_LAZY | RTLD_NODELETE is how Qt loads the plugin
[12:41] <DavidRedondo>  *  RTLD_LAZY | RTLD_NODELETE is how Qt loads the plugin I think (4097)
[12:49] <fvogt> Does it work if you put struct xdg_popup {}; into IS_PLUGIN?
[...]
[13:03] <DavidRedondo> fvogt: no that doesn't change anything
[13:04] <fvogt> I could reproduce it locally
[13:04] <fvogt> "typeinfo for xdg_popup*" is a weak symbol in both objects, so should exist only once
[13:05] <fvogt> a.type().hash_code() is different with libc++ though
[...]
[13:07] <DavidRedondo> fvogt: It also fails if both objects have a defintion of xdg_popup
[13:08] <fvogt> https://github.com/llvm/llvm-project/blob/6009708b4367171ccdbf4b5905cb6a803753fe18/libcxx/include/typeinfo#L133
[13:08] <fvogt> With -D_LIBCPP_TYPEINFO_COMPARISON_IMPLEMENTATION=2 it works (as expected)
[13:08] <DavidRedondo> So the question is why do we not have a unique_copy of the typeinfo
[13:09] <fvogt> Maybe the scope of the weak symbols is wrong
[13:10] <fvogt> Oh, hm
[...]
[13:10] <fvogt> I think I mixed up my binaries, the typeinfo with libc++ is not weak?
[13:13] <DavidRedondo> fvogt: for libc++ I have 
>         0000000000003d98 d typeinfo for xdg_popup
>         0000000000003da8 d typeinfo for xdg_popup*
>         0000000000002020 r typeinfo name for xdg_popup
>         0000000000002014 r typeinfo name for xdg_popup*
[13:13] <fvogt> I suggest readelf -sW, easier to read
[13:14] <DavidRedondo> but the same with libstdc++
[13:14] <lunarequest[M]> would there be something i can do to fix it?
[13:15] <fvogt> https://gcc.gnu.org/legacy-ml/gcc-patches/2009-07/msg01239.html
[13:16] <DavidRedondo> fvogt:
>         libc++
>             10: 0000000000003da8    32 OBJECT  LOCAL  DEFAULT   19 typeinfo for xdg_popup*
>             11: 0000000000002014    12 OBJECT  LOCAL  DEFAULT   14 typeinfo name for xdg_popup*
>             12: 0000000000002020    11 OBJECT  LOCAL  DEFAULT   14 typeinfo name for xdg_popup
>             13: 0000000000003d98    16 OBJECT  LOCAL  DEFAULT   19 typeinfo for xdg_popup
>         libstdc++
>             10: 0000000000003dc8    32 OBJECT  LOCAL  DEFAULT   19 typeinfo for xdg_popup*
>             11: 0000000000002014    12 OBJECT  LOCAL  DEFAULT   14 typeinfo name for xdg_popup*
>             12: 0000000000002020    11 OBJECT  LOCAL  DEFAULT   14 typeinfo name for xdg_popup
>             13: 0000000000003db8    16 OBJECT  LOCAL  DEFAULT   19 typeinfo for xdg_popup
[13:16] <fvogt> libstdc++ does the equivalent of D_LIBCPP_TYPEINFO_COMPARISON_IMPLEMENTATION=2 by default
[13:17] <DavidRedondo> Interestingly if xdg_popup is defined the typeinfo is weak
[13:17] <DavidRedondo> but the any cast still fails
[13:17] <fvogt> Ah, that explains why it changed for me
[13:18] <DavidRedondo> So what should we do, and who is we in that case
[13:18] <DavidRedondo> Qt, KDE, distros?
[13:19] <DavidRedondo> https://lists.llvm.org/pipermail/llvm-dev/2014-June/073465.html
[13:20] <fvogt> If it's weak in the lib it should work
[13:22] <DavidRedondo> Somehow it still  doesn't
[13:24] <fvogt> binding file ./plugin.so [0] to ./plugin.so [0]: normal symbol `_ZTIP9xdg_popup'
[13:27] <fvogt> https://github.com/llvm/llvm-project/issues/10550#issuecomment-998360621
[...]
[13:33] <DavidRedondo> fvogt I think if xdg-Popup is not defined it can't use typeinfo at all?
[13:34] <fvogt> DavidRedondo: Technically it should be, due to COMDAT merging, but only wirh -rdynamic in that case (I think)
[13:34] <fvogt> For some reason even with -rdynamic, clang does not export the typeinfo symbol from the binary
[13:34] <DavidRedondo> typeinfo(uncomplete_type) doesn't work 
[13:34] <DavidRedondo> So it should fallback to the fallback counter thing?
[13:35] <DavidRedondo> but even if I define xdg_popup  (get_any().type() == typeid(xdg_popup)) is false
[13:35] <fvogt> With it defined (i.e. weak) in the executable and LD_PRELOAD it works
[13:37] <DavidRedondo> __get_fallback_typeid is only a local symbol
[13:37] <DavidRedondo> Are you preloading the plugin?
[13:38] <fvogt> Yes, that's the only way to force the executable to use the plugin's symbol
[13:38] <fvogt> I can't get the plugin to use the executable's symbol as -rdynamic doesn't work for some reason
[13:40] <DavidRedondo> I can't make the preloading work either 
[13:40] <DavidRedondo> Anything else 
[13:40] <DavidRedondo>  * Anything else  I need to do?
[13:42] <fvogt> Might be I did the definition in both objects
[13:42] <fvogt> Not sure what the best option is, I think something is wrong with the linking still... ELF is weird
[13:42] * fvogt will bbl
[13:46] <DavidRedondo> Just tell people to compile with the libc++ define?
[14:18] <fvogt> DavidRedondo: Supposedly it can be set during llvm build already
[14:18] <fvogt> I'll try to ask some toolchain guys here, maybe they already know
[14:23] <DavidRedondo> Whole linking and symbol thing is black magic to me 
[14:23] <DavidRedondo> Not sure who is right or wrong here
[...]
[14:27] <DavidRedondo> I wonder if this is the same/similar bug
[14:27] <DavidRedondo> https://github.com/llvm/llvm-project/issues/48743
[...]
[17:16] <fvogt> I'll try to ask the toolchain guys tomorrow, but FWICT there are two options: a) Use RTLD_GLOBAL + declaration of xdg_popup to make it weak b) Tell distros to set _LIBCPP_TYPEINFO_COMPARISON_IMPLEMENTATION=2

[Comment 9 Sam James 2024-02-12 18:33:15 UTC]

Reopened the upstream LLVM bug.

[Comment 10 Andreas Sturmlechner 2024-04-01 07:36:05 UTC]

Shall we detect this configuration from e.g. plasma-meta and bail out with referencing this bug as long as it is not fixed upstream?

[Comment 11 Sam James 2024-05-07 15:21:02 UTC]

(In reply to Andreas Sturmlechner from comment #10)
> Shall we detect this configuration from e.g. plasma-meta and bail out with
> referencing this bug as long as it is not fixed upstream?

I think that's better than nothing for now. I am open-minded to making the change in libc++ but I'm not yet sure if we should. That can/should be done separately.

[Comment 12 unhappy-ending 2024-05-07 23:19:41 UTC]

I've hit this bug, too. I tried the libc++ workaround _LIBCPP_TYPEINFO_COMPARISON_IMPLEMENTATION=2 (and LIBCXX_TYPEINFO_COMPARISON_IMPLEMENTATION=2 as well) and I still get the same issue. Is there a proper way to do that? This is how I tried it initially:

MYCMAKEARGS="-DLIBCXX_TYPEINFO_COMPARISON_IMPLEMENTATION=2 -D_LIBCPP_TYPEINFO_COMPARISON_IMPLEMENTATION=2"

And I also ended up copying the libcxx ebuild over to a local overlay and added in the arguments there.

Did I do something wrong?

[Comment 13 Neko-san 2024-05-07 23:41:01 UTC]

As a user of Plasma 6 with the default libc++ configuration, myself, I'm not quite sure what the consequences would be for other parts of the Plasma 6 ecosystem (apps that might have it as a dependency?) in the long term that aren't affected by this if plasmashell gets blocked as being proposed...

And having to change the entire system to stdlibc++ just because right-clicking doesn't work on the task tray and desktop is kind of... bleh.

[Comment 14 Michael Egger 2024-05-08 06:46:41 UTC]

(In reply to unhappy-ending from comment #12)
> I've hit this bug, too. I tried the libc++ workaround
> _LIBCPP_TYPEINFO_COMPARISON_IMPLEMENTATION=2 (and
> LIBCXX_TYPEINFO_COMPARISON_IMPLEMENTATION=2 as well) and I still get the
> same issue. Is there a proper way to do that? This is how I tried it
> initially:
> 
> MYCMAKEARGS="-DLIBCXX_TYPEINFO_COMPARISON_IMPLEMENTATION=2
> -D_LIBCPP_TYPEINFO_COMPARISON_IMPLEMENTATION=2"
> 
> And I also ended up copying the libcxx ebuild over to a local overlay and
> added in the arguments there.
> 
> Did I do something wrong?

On my machine the following works:

# cat /etc/portage/env/libcxx-typeinfo-comparison 
# I suggest to build libc++ with -DLIBCXX_TYPEINFO_COMPARISON_IMPLEMENTATION=2,
# which mirrors libstdc++ behavior.
# See https://bugs.kde.org/show_bug.cgi?id=479679#c23

MYCMAKEARGS="-DLIBCXX_TYPEINFO_COMPARISON_IMPLEMENTATION=2"


# cat /etc/portage/package.env/workarounds
sys-libs/libcxx libcxx-typeinfo-comparison
sys-libs/libcxxabi libcxx-typeinfo-comparison

[Comment 15 unhappy-ending 2024-05-10 00:03:46 UTC]

(In reply to Michael Egger from comment #14)
> On my machine the following works:
> 
> # cat /etc/portage/env/libcxx-typeinfo-comparison 
> # I suggest to build libc++ with
> -DLIBCXX_TYPEINFO_COMPARISON_IMPLEMENTATION=2,
> # which mirrors libstdc++ behavior.
> # See https://bugs.kde.org/show_bug.cgi?id=479679#c23
> 
> MYCMAKEARGS="-DLIBCXX_TYPEINFO_COMPARISON_IMPLEMENTATION=2"
> 
> 
> # cat /etc/portage/package.env/workarounds
> sys-libs/libcxx libcxx-typeinfo-comparison
> sys-libs/libcxxabi libcxx-typeinfo-comparison

Did exactly this, with sane *FLAGS just to be sure, and it still doesn't work for me. What version are you using? I'm assuming your libcxx and libcxxabi are static-libs?

[Comment 16 Michael Egger 2024-05-10 08:20:08 UTC]

(In reply to unhappy-ending from comment #15)
> (In reply to Michael Egger from comment #14)
> > On my machine the following works:
> > 
> > # cat /etc/portage/env/libcxx-typeinfo-comparison 
> > # I suggest to build libc++ with
> > -DLIBCXX_TYPEINFO_COMPARISON_IMPLEMENTATION=2,
> > # which mirrors libstdc++ behavior.
> > # See https://bugs.kde.org/show_bug.cgi?id=479679#c23
> > 
> > MYCMAKEARGS="-DLIBCXX_TYPEINFO_COMPARISON_IMPLEMENTATION=2"
> > 
> > 
> > # cat /etc/portage/package.env/workarounds
> > sys-libs/libcxx libcxx-typeinfo-comparison
> > sys-libs/libcxxabi libcxx-typeinfo-comparison
> 
> Did exactly this, with sane *FLAGS just to be sure, and it still doesn't
> work for me. What version are you using? I'm assuming your libcxx and
> libcxxabi are static-libs?

Yes, those are the versions and USE flags I'm using. I masked llvm 18 and related libraries completely.

sys-libs/libcxx-17.0.6::gentoo was built with the following:
USE="(clang) (libcxxabi) static-libs verify-sig -test" ABI_X86="(32) (64) (-x32)"
FEATURES="usersync strict-keepdir unmerge-logs binpkg-multi-instance sandbox strict news merge-wait binpkg-logs ebuild-locks binpkg-dostrip unmerge-orphans merge-sync buildpkg userfetch xattr binpkg-docompress assume-digests network-sandbox split-log pkgdir-index-trusted parallel-fetch pid-sandbox clean-logs ipc-sandbox preserve-libs protect-owned fixlafiles warn-on-large-env config-protect-if-modified sfperms userpriv qa-unresolved-soname-deps unknown-features-warn nodoc buildpkg-live distlocks multilib-strict usersandbox"

sys-libs/libcxxabi-17.0.6::gentoo was built with the following:
USE="(clang) static-libs verify-sig -test" ABI_X86="(32) (64) (-x32)"
FEATURES="usersync strict-keepdir unmerge-logs binpkg-multi-instance sandbox strict news merge-wait binpkg-logs ebuild-locks binpkg-dostrip unmerge-orphans merge-sync buildpkg userfetch xattr binpkg-docompress assume-digests network-sandbox split-log pkgdir-index-trusted parallel-fetch pid-sandbox clean-logs ipc-sandbox preserve-libs protect-owned fixlafiles warn-on-large-env config-protect-if-modified sfperms userpriv qa-unresolved-soname-deps unknown-features-warn nodoc buildpkg-live distlocks multilib-strict usersandbox"

To be sure I also rebuild all of dev-qt, kde-frameworks and kde-plasma packages.

[Comment 17 unhappy-ending 2024-05-10 09:16:38 UTC]

(In reply to Michael Egger from comment #16)
> 
> Yes, those are the versions and USE flags I'm using. I masked llvm 18 and
> related libraries completely.
> 
> sys-libs/libcxx-17.0.6::gentoo was built with the following:
> USE="(clang) (libcxxabi) static-libs verify-sig -test" ABI_X86="(32) (64)
> (-x32)"
> FEATURES="usersync strict-keepdir unmerge-logs binpkg-multi-instance sandbox
> strict news merge-wait binpkg-logs ebuild-locks binpkg-dostrip
> unmerge-orphans merge-sync buildpkg userfetch xattr binpkg-docompress
> assume-digests network-sandbox split-log pkgdir-index-trusted parallel-fetch
> pid-sandbox clean-logs ipc-sandbox preserve-libs protect-owned fixlafiles
> warn-on-large-env config-protect-if-modified sfperms userpriv
> qa-unresolved-soname-deps unknown-features-warn nodoc buildpkg-live
> distlocks multilib-strict usersandbox"
> 
> sys-libs/libcxxabi-17.0.6::gentoo was built with the following:
> USE="(clang) static-libs verify-sig -test" ABI_X86="(32) (64) (-x32)"
> FEATURES="usersync strict-keepdir unmerge-logs binpkg-multi-instance sandbox
> strict news merge-wait binpkg-logs ebuild-locks binpkg-dostrip
> unmerge-orphans merge-sync buildpkg userfetch xattr binpkg-docompress
> assume-digests network-sandbox split-log pkgdir-index-trusted parallel-fetch
> pid-sandbox clean-logs ipc-sandbox preserve-libs protect-owned fixlafiles
> warn-on-large-env config-protect-if-modified sfperms userpriv
> qa-unresolved-soname-deps unknown-features-warn nodoc buildpkg-live
> distlocks multilib-strict usersandbox"
> 
> To be sure I also rebuild all of dev-qt, kde-frameworks and kde-plasma
> packages.

Ok, I'm on 18.1.5. I will rebuild qt and kde first and then roll back to 17. I'll report afterwards. Even if this isn't useful I just want to rule out a possible missed step.

[Comment 18 unhappy-ending 2024-05-10 12:45:44 UTC]

All right, I just finished rebuilding dev-qt, kde-frameworks, and kde-plasma. I can confirm that after a reboot it is working. It's not enough to just build the two libraries, I had to rebuild the above as well. I haven't pinpointed what exactly it is and probably won't hunt for it. I can confirm that after I previously built libcxx & libcxxabi with the MYCMAKEARGS flag I had also rebuilt plasma-workspace which wasn't enough. So, there is something further down the dependency tree that requires the rebuild before the libcxx change kicks in.

Not sure if libcxxabi also requires the change and I don't want to rebuild 150 packages to find out. If I ever get around to it, I'll report back here.

[Comment 19 unhappy-ending 2024-05-11 02:19:15 UTC]

(In reply to Michael Egger from comment #14)
> # cat /etc/portage/package.env/workarounds
> sys-libs/libcxx libcxx-typeinfo-comparison
> sys-libs/libcxxabi libcxx-typeinfo-comparison

libcxxabi MYCMAKEARGS=-DLIBCXX_TYPEINFO_COMPARISON_IMPLEMENTATION=2 doesn't seem required. Did Right clicking works after full rebuild.

[Comment 20 Sam James 2024-05-11 02:22:27 UTC]

(In reply to Neko-san from comment #13)
> As a user of Plasma 6 with the default libc++ configuration, myself, I'm not
> quite sure what the consequences would be for other parts of the Plasma 6
> ecosystem (apps that might have it as a dependency?) in the long term that
> aren't affected by this if plasmashell gets blocked as being proposed...
> 
> And having to change the entire system to stdlibc++ just because
> right-clicking doesn't work on the task tray and desktop is kind of... bleh.

I don't think it is overkill in the sense of "well, the software doesn't work correctly at all, and you're lucky it shows up via a trivial obvious part, rathe r than eating your data."

But yes, if we add such a bail out, it should be either a warning, or an error with an env-var to skip it.

[Comment 21 kingfared 2024-05-25 11:03:40 UTC]

With inspiration from comments here I tested some dependencies on my laptop with musl/llvm profile, building only qtwayland with libcxx cmake flag did make right click work again.

[Comment 22 Gonçalo Negrier Duarte 2024-05-28 16:51:38 UTC]

(In reply to kingfared from comment #21)
> With inspiration from comments here I tested some dependencies on my laptop
> with musl/llvm profile, building only qtwayland with libcxx cmake flag did
> make right click work again.

You sure! I try the `MYCMAKEARGS="-DLIBCXX_TYPEINFO_COMPARISON_IMPLEMENTATION=2"` only on dev-qt/qtwayland and the right click didn't get solved. But I on the glibc/llvm profile tho.

[Comment 23 Gonçalo Negrier Duarte 2024-05-28 17:04:22 UTC]

(In reply to Gonçalo Negrier Duarte from comment #22)
> (In reply to kingfared from comment #21)
> > With inspiration from comments here I tested some dependencies on my laptop
> > with musl/llvm profile, building only qtwayland with libcxx cmake flag did
> > make right click work again.
> 
> You sure! I try the
> `MYCMAKEARGS="-DLIBCXX_TYPEINFO_COMPARISON_IMPLEMENTATION=2"` only on
> dev-qt/qtwayland and the right click didn't get solved. But I on the
> glibc/llvm profile tho.


I also need to rebuild sys-libs/libcxx as well to work

[Comment 24 Andreas Sturmlechner 2024-06-07 22:49:57 UTC]

(In reply to Sam James from comment #20)
> But yes, if we add such a bail out, it should be either a warning, or an
> error with an env-var to skip it.
Not saying this is a real blocker, but if we have those users, they shall really be warned about this footgun.

[Comment 25 Sam James 2024-06-13 00:47:00 UTC]

I'm going to add the workaround warning for now.

I still need to find someone to speak to about if we should implement the libc++ setting distro-wide (or someone else is free to do that).

[Comment 26 Larry the Git Cow 2024-06-13 00:58:42 UTC]

The bug has been referenced in the following commit(s):

https://gitweb.gentoo.org/proj/kde.git/commit/?id=3c18c4e47fdf33fc3ade6415e554a5e7bb4b2776

commit 3c18c4e47fdf33fc3ade6415e554a5e7bb4b2776
Author:     Sam James <[e-mail]>
AuthorDate: 2024-06-13 00:57:35 +0000
Commit:     Sam James <[e-mail]>
CommitDate: 2024-06-13 00:58:32 +0000

    kde-plasma/plasma-meta: add ewarn for libc++
    
    I still need to find someone to speak to about if we should implement the
    libc++ setting distro-wide (or someone else is free to do that).
    
    Bug: https://bugs.kde.org/479679
    Bug: https://bugs.gentoo.org/923292
    Signed-off-by: Sam James <[e-mail]>

 kde-plasma/plasma-meta/plasma-meta-6.1.49.9999.ebuild | 13 +++++++++++++
 kde-plasma/plasma-meta/plasma-meta-9999.ebuild        | 13 +++++++++++++
 2 files changed, 26 insertions(+)

[Comment 27 Larry the Git Cow 2024-06-13 01:00:24 UTC]

The bug has been referenced in the following commit(s):

https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=3b4f3c13ff83e5a9b0470252393279b02c323d7f

commit 3b4f3c13ff83e5a9b0470252393279b02c323d7f
Author:     Sam James <[e-mail]>
AuthorDate: 2024-06-13 00:57:35 +0000
Commit:     Sam James <[e-mail]>
CommitDate: 2024-06-13 00:59:48 +0000

    kde-plasma/plasma-meta: add ewarn for libc++
    
    I still need to find someone to speak to about if we should implement the
    libc++ setting distro-wide (or someone else is free to do that).
    
    Bug: https://bugs.kde.org/479679
    Bug: https://bugs.gentoo.org/923292
    Signed-off-by: Sam James <[e-mail]>

 kde-plasma/plasma-meta/plasma-meta-6.0.90-r1.ebuild | 13 +++++++++++++
 1 file changed, 13 insertions(+)

[Comment 28 Sam James 2024-06-13 01:00:38 UTC]

... and therefore no longer a blocker.

[Comment 29 Rin Cat 2024-06-19 13:53:12 UTC]

(In reply to Larry the Git Cow from comment #27)
> The bug has been referenced in the following commit(s):
> 
> https://gitweb.gentoo.org/repo/gentoo.git/commit/
> ?id=3b4f3c13ff83e5a9b0470252393279b02c323d7f
> 
> commit 3b4f3c13ff83e5a9b0470252393279b02c323d7f
> Author:     Sam James <[e-mail]>
> AuthorDate: 2024-06-13 00:57:35 +0000
> Commit:     Sam James <[e-mail]>
> CommitDate: 2024-06-13 00:59:48 +0000
> 
>     kde-plasma/plasma-meta: add ewarn for libc++
>     
>     I still need to find someone to speak to about if we should implement the
>     libc++ setting distro-wide (or someone else is free to do that).
>     
>     Bug: https://bugs.kde.org/479679
>     Bug: https://bugs.gentoo.org/923292
>     Signed-off-by: Sam James <[e-mail]>
> 
>  kde-plasma/plasma-meta/plasma-meta-6.0.90-r1.ebuild | 13 +++++++++++++
>  1 file changed, 13 insertions(+)

It should be "-DLIBCXX_TYPEINFO_COMPARISON_IMPLEMENTATION=2" not =1. Also for what I tried, dev-qt/qtwayland need to be rebuild with the flag.

[Comment 30 unhappy-ending 2024-06-24 02:31:45 UTC]

(In reply to Rin Cat from comment #29)
> It should be "-DLIBCXX_TYPEINFO_COMPARISON_IMPLEMENTATION=2" not =1. Also
> for what I tried, dev-qt/qtwayland need to be rebuild with the flag.

Just to clarify, dev-qt/qtwayland doesn't need the flag, it just needs to be rebuilt after the libcxx is rebuilt with MYCMAKEARGS=-DLIBCXX_TYPEINFO_COMPARISON_IMPLEMENTATION=2.

[Comment 31 Sam James 2024-06-24 02:54:04 UTC]

It depends on if you're passing the similarly-named but different flag for CPPFLAGS, yeah. I'll tweak the PR.

[Comment 32 Larry the Git Cow 2024-06-25 22:31:16 UTC]

The bug has been referenced in the following commit(s):

https://gitweb.gentoo.org/proj/kde.git/commit/?id=9e81906b42a6f4963297b2c241fc25d245581443

commit 9e81906b42a6f4963297b2c241fc25d245581443
Author:     Sam James <[e-mail]>
AuthorDate: 2024-06-23 17:49:28 +0000
Commit:     Sam James <[e-mail]>
CommitDate: 2024-06-25 02:44:56 +0000

    kde-plasma/plasma-meta: fix libc++ workaround advice
    
    Rin Cat points out on the bug that it should be =2, not =1. Also, clarify
    the need to rebuild packages afterwards.
    
    Bug: https://bugs.gentoo.org/923292
    Signed-off-by: Sam James <[e-mail]>

 kde-plasma/plasma-meta/plasma-meta-6.1.49.9999.ebuild | 3 ++-
 kde-plasma/plasma-meta/plasma-meta-9999.ebuild        | 3 ++-
 2 files changed, 4 insertions(+), 2 deletions(-)

[Comment 33 Larry the Git Cow 2024-06-25 22:33:13 UTC]

The bug has been referenced in the following commit(s):

https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=1c83a085d4c37c247d844dfc0b0f9a76e642763b

commit 1c83a085d4c37c247d844dfc0b0f9a76e642763b
Author:     Sam James <[e-mail]>
AuthorDate: 2024-06-23 17:49:28 +0000
Commit:     Sam James <[e-mail]>
CommitDate: 2024-06-25 22:32:06 +0000

    kde-plasma/plasma-meta: fix libc++ workaround advice
    
    Rin Cat points out on the bug that it should be =2, not =1. Also, clarify
    the need to rebuild packages afterwards.
    
    Bug: https://bugs.gentoo.org/923292
    Signed-off-by: Sam James <[e-mail]>

 kde-plasma/plasma-meta/plasma-meta-6.1.1.ebuild | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)