Since when I upgrade to KDE 3.4.0, and even when I upgraded to KDE 3.4.1, juk crashes, and the backtrace shows traces of taglib in there (I haven't it handy); I use taglib 1.3.1, a stable version. Until a little time ago juk-3.3.4 worked, now it doesn't either. Is this known anyhow? I'm going to re-install it and provide the backtrace. Reproducible: Always Steps to Reproduce: 1. 2. 3.
Created attachment 62874 [details] Backtrace from KCrash #1 (good) This is the backtrace I was referring to, it's very specific and I had it saved on my hard disk, before unmerging juk and remerging it.
Created attachment 62875 [details] Backtrace from KCrash #2 (bad) This is a backtrace I got now, after unmerging and (after some time) remerging juk. It is stranger.
Comment on attachment 62874 [details] Backtrace from KCrash #1 (good) This is the backtrace I was referring to, it's very specific and I had it saved on my hard disk, before unmerging juk and remerging it.
Maybe you switched to gcc 3.4 without recompiling c++ applications? Please always post your 'emerge info'.
Thanks a lot for your tip! Err, something like that... juk was linking to libstdc++ versions 5 and 6, because some libraries (including taglib) were compiled with -V5. And libtool reported a warning about that. Shouldn't such warnings be "einfo"-ed? I also use enotice, so I would have caught them. But sorry, should I recompile *all* C++ applications when upgrading? I.e., should I do revdep-rebuild --soname libstdc++.so.5? And wouldn't that be risky for python and thus portage?
Changing resolution...
As you can see from bug 61146, running revdep-rebuild --soname libstdc++.so.5 is necessary, and I don't think it can have side effects for portage... As for the warnings, we cannot change them as they are not printed by the ebuild, but definitely the gcc maintainers should have put some warning in the gcc ebuild for those upgrading to 3.4.x. *** This bug has been marked as a duplicate of 61146 ***
