kde-base/kig-3.5.7 crashes if compiled with kdeenablefinal use flag. Kcrash says: could not find the necessary kig library, check your installation. emerge --info and bakctrace are allowed. Reproducible: Always Steps to Reproduce: 1. 2. 3. Expected Results: I thing the problem should be fixed, or the useflag disabled in the ebuild. kig works well without kdeenablefinal useflag.
Created attachment 127925 [details] emerge info and Kcrash bakctrace emerge info and Kcrash bakctrace
Please, don't attach tarballs unless absolutely necessary. You are forcing everyone to download and manually unpack the thing instead of viewing it in the browser.
Created attachment 127929 [details] emerge info
Created attachment 127931 [details] Kcrash-backtrace
p.s.: off course, using kde-base/kededu instead of kde-base/kig, I have the same issue.
First of all, please read the kdeenablefinal USE flag's description: kdeenablefinal - EXPERIMENTAL: KDE ebuilds will use the enable-final flag, yielding compilation speedups at the cost of heavy mem usage and potentially causing problems. We strongly discourage setting this. That said, kig works fine for me even with kdeenablefinal set. Your backtrace is unfortunately useless as it does not contain the necessary information. Please read this document to find out how to get meaningful backtraces: http://www.gentoo.org/proj/en/qa/backtraces.xml Try running revdep-rebuild -X (from app-portage/gentoolkit), temporarily disable ccache and then try re-emerging kig.
(In reply to comment #6) > First of all, please read the kdeenablefinal USE flag's description: > > I well know the `euse -i kdeenablefinal` info, and that the reason because I've tried to disable it. > That said, kig works fine for me even with kdeenablefinal set. > ok. so the problem should be in my installation. give me please some time to investigate before put invalid this bug. > Your backtrace is unfortunately useless as it does not contain the necessary information. > Please read this document to find out how to get meaningful backtraces: > http://www.gentoo.org/proj/en/qa/backtraces.xml > [quote] KDE crash handler's notes ... On this dialog there is a "Backtrace" tab ... That backtrace is usually good enough for reporting a problem. [/quote] I'm just a noob, and I've submitted the backtrace from Kcrash. I have drqonqi installed in my system. > Try running revdep-rebuild -X (from app-portage/gentoolkit), temporarily > disable ccache and then try re-emerging kig. > from revdep-rebuild -X -pv : Assigning packages to ebuilds... Nothing to rebuild I've just disabled ccache before submitting this bug. again: give please some time to reanalyse my system.
(In reply to comment #7) > again: give please some time to reanalyse my system. First of all, should I have sounded harsh, I'm sorry. I didn't mean to be. About you being a newbie: It's true, I'm currently hungry but I don't habitually eat newbies so don't worry. ;-) We all started as newbies once so don't worry about that either. We'll gladly provide assistance in getting this fixed.
Created attachment 127980 [details] $ strace -f kig >kig-strace.txt 2>& (In reply to comment #8) > (In reply to comment #7) > > again: give please some time to reanalyse my system. > > First of all, should I have sounded harsh. > you was not harsh at all. you just exposed me your technical point of view and gave me some useful suggestions. it's not your blame if your kig is working, while mine not ... I spoke of me as a newbie just to explain why I'm not able to identify a meaningless backtrace. anyway, I've not solved my problem and I want to understand it. I try to get a backtrace directly from gdb, but I was not able to launch kig with --nocrashhandler option. so, I try to use strace and to submit you its output. before starting I've recompiled kig (and just kig) without LDFLAGS, and with CFLAGS="-march=athlon64 -O2 -gdb", FEATURES="buildpkg parallel-fetch splitdebug" and USE="kig-scripting kdeenablefinal" if you like, may also recompile kdelibs with some other parameters, but I cannot recompile all world, as the howto suggests :roll: .
I've also compared a good strace (without kdeenablefinal) with a bad strace. first difference happens on line 4693 after opening /lib/librt.so.1 I don't know what does it mean, but I submit both outputs.
Created attachment 128006 [details] good-strace good-strace file is long too much. forced using bzip-tar.
Marco, while the output of strace can sometimes help to diagnose a problem, it doesn't help here. Compiling at least kdelibs with debug flags as mentioned in the backtrace guide might help but it could as well turn out to be insufficient. Another option would be to put "-kdeenablefinal" in your USE flags in /etc/make.conf and re-emerge kig if it works for you without the kdeenablefinal USE flag.
Created attachment 128032 [details] last backtrace (In reply to comment #12) > Marco, while the output of strace can sometimes help to diagnose a problem, it > doesn't help here. > afraid. > Compiling at least kdelibs with debug flags as mentioned in the backtrace guide > might help but it could as well turn out to be insufficient. that's my last attempt. it's seems no more intersting than before, but I attached it the same. > Another option > would be to put "-kdeenablefinal" in your USE flags in /etc/make.conf Yes. Now I put it in /etc/portage/package.keywords. it works for me, but give no change to understand the issue. Thank for your support.
Well, I'd suggest to deactivate kdeenablefinal globally (in make.conf) but at least it works for you now.
