Summary: | kde-base/kdelibs breaks KDE printing when compiled w/ -O3 | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Paolo Pedroni <paolo.pedroni> |
Component: | [OLD] KDE | Assignee: | Gentoo KDE team <kde> |
Status: | RESOLVED FIXED | ||
Severity: | major | CC: | eggie, esigra, ffl, jakub, unclegimpy |
Priority: | Highest | ||
Version: | 2006.1 | ||
Hardware: | AMD64 | ||
OS: | Linux | ||
URL: | http://forums.gentoo.org/viewtopic-t-467803.html | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- |
Description
Paolo Pedroni
2006-09-19 04:51:04 UTC
Could you please explain in further detail the behaviour that you are experiencing? (In reply to comment #1) > Could you please explain in further detail the behaviour that you are > experiencing? > I will try. If kdelibs is compiled with glibc-2.4, gcc-4.11 and -O3 in the C(XX)FLAGS the "Printer Settings" tab in the properties menu of every printer in the system is missing and it's impossible to add any printer via the KDE Control Center. If kdelibs is compiled with -O2 C(XX)FLAGS everything works (kind of) correctly. I can confirm this behaviour both with kde-3.5.2 and with kde-3.5.4. Do you need any more details? Can you confirm this bug for kde-3.5.5? (In reply to comment #3) > Can you confirm this bug for kde-3.5.5? > Is it out? I will try later next week, on the office machine with unstable KDE. (In reply to comment #4) > (In reply to comment #3) > > Can you confirm this bug for kde-3.5.5? > > > > Is it out? I will try later next week, on the office machine with unstable KDE. > Not yet, but almost. (In reply to comment #3) > Can you confirm this bug for kde-3.5.5? > Yes, I can. Same behaviour as kdelibs-3.5.4-r1 and kdelibs-3.5.2-r6. I can not confirm this with kdelibs-3.5.5-r2. Paolo: can you confirm that? (In reply to comment #8) > Paolo: can you confirm that? > Nope, I still get the problem. (In reply to comment #9) > (In reply to comment #8) > > Paolo: can you confirm that? > > > > Nope, I still get the problem. > Bump! (In reply to comment #10) > (In reply to comment #9) > > (In reply to comment #8) > > > Paolo: can you confirm that? > > > > > > > Nope, I still get the problem. > > > > Bump! Bump again! This still happens with kdelibs-3.5.5-r8. (In reply to comment #11) > Bump again! This still happens with kdelibs-3.5.5-r8. If you still get this with kdelibs-3.5.6-r2 please file a bug upstream including the failure and post the URL here. *** Bug 155922 has been marked as a duplicate of this bug. *** *** Bug 168967 has been marked as a duplicate of this bug. *** (In reply to comment #12) > If you still get this with kdelibs-3.5.6-r2 please file a bug upstream > including the failure and post the URL here. > Could something like the following be added to the ebuild until the problem is fixed upstream? # work around bug #148180, -O3 miscompilation use amd64 && replace-flags "-O3" "-O2" # see bug #148180 There is already a similar thing for bug #120858, a problem with -Os, and it's a lot easier than trying to remember to edit make.conf everytime the package is built. Filtering the flag now, sorry that it took that long. Better is not to use -O3 at all, though. I can also confirm this problem on x86, while the flag now only is filtered for amd64. Any chance of adding the replace-flags for x86 as well? (In reply to comment #17) > I can also confirm this problem on x86, while the flag now only is filtered for > amd64. Any chance of adding the replace-flags for x86 as well? Yes, I will add it later today. I'm with you sinners ;) and am using -O3 myself (which neither of us should) and was wondering why my PPDs couldn't be parsed... :) Re-opening. While I have a strong resistance from going off-topic, it's not strong enough to keep me from asking: why are we sinners and why should neither of us use -O3? If it is so utterly evil, why does GCC have that flag anyway? Why doesn't portage have an overall replace-flags to replace -O3 by -O2 or something? The short answer is: -O3 undoubtedly has its merits in some occasions but it simply shouldn't be set globally because it activates optimisations that aren't suitable for general use. The longer answer I've shamelessly stolen from http://bugs.gentoo.org/show_bug.cgi?id=68282 : -O3: This is the highest level of optimization possible, and also the riskiest. It will take a longer time to compile your code with this option, and in fact it should not be used system-wide with gcc 4.x. The behavior of gcc has changed significantly since version 3.x. In 3.x, -O3 has been shown to lead to marginally faster execution times over -O2, but this is no longer the case with gcc 4.x. Compiling all your packages with -O3 will result in larger binaries that require more memory, and will significantly increase the odds of compilation failure or unexpected program behavior (including errors). The downsides outweigh the benefits; remember the principle of diminishing returns. Using -O3 is not recommended for gcc 4.x. For those reasons it's not on our list of reasonable CFLAGS either: "Reasonable CFLAGS are -march=, -mcpu=, -mtune= (depending upon arch), -O2, -Os and -fomit-frame-pointer. [...] If a package breaks with other (insane) CFLAGS, it is perfectly OK to close the bug with a WONTFIX suggesting that the user picks more sensible global CFLAGS. Similarly, if you suspect that a bug is caused by insane CFLAGS, an INVALID resolution is suitable." "[About replace-flags]. This is most commonly used to replace -Os with -O2 (or -O3 with -O2 if you are feeling kind)." (Source: http://devmanual.gentoo.org/ebuild-writing/functions/src_compile/build-environment/index.html ) Yes, I'm using -O3 globally myself because I'm stupid ;) but I can usually wiggle myself out of the problems it causes (e. g., I *did* find a horrible workaround for my PPD problem eventually) but I don't expect that from any user and that's why I discourage the use of -O3. And, actually, I just convinced myself to switch to -O2. :-) Back to the topic at hand: All kdelibs ebuilds are now replacing -O3 with -O2 unconditionally (i. e. on all arches). I've just committed this change to CVS. |