As is shown in the forum thread above, kdelibs messes up printing if built with -O3 CFLAGS and gcc-4.1.1 (I can confirm that behaviour with both stable kdelibs-3.5.2-r6 and unstable kdelibs-3.5.4-r1). It would be nice if the ebuild filtered the -O3 flag automagically. # emerge --info Portage 2.1.1 (default-linux/amd64/2006.1/desktop, gcc-4.1.1, glibc-2.4-r3, 2.6.17-gentoo-r8 x86_64) ================================================================= System uname: 2.6.17-gentoo-r8 x86_64 AMD Athlon(tm) 64 X2 Dual Core Processor 4600+ Gentoo Base System version 1.12.5 Last Sync: Tue, 19 Sep 2006 07:30:08 +0000 distcc 2.18.3 x86_64-pc-linux-gnu (protocols 1 and 2) (default port 3632) [enabled] ccache version 2.3 [enabled] app-admin/eselect-compiler: [Not Present] dev-java/java-config: 1.2.11-r1 dev-lang/python: 2.4.3-r1 dev-python/pycrypto: 2.0.1-r5 dev-util/ccache: 2.3 dev-util/confcache: [Not Present] sys-apps/sandbox: 1.2.17 sys-devel/autoconf: 2.13, 2.59-r7 sys-devel/automake: 1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.6-r2 sys-devel/binutils: 2.16.1-r3 sys-devel/gcc-config: 1.3.13-r3 sys-devel/libtool: 1.5.22 virtual/os-headers: 2.6.11-r2 ACCEPT_KEYWORDS="amd64" AUTOCLEAN="yes" CBUILD="x86_64-pc-linux-gnu" CFLAGS="-march=k8 -O3 -pipe -fomit-frame-pointer" CHOST="x86_64-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/kde/3.5/env /usr/kde/3.5/share/config /usr/kde/3.5/shutdown /usr/share/X11/xkb /usr/share/config" CONFIG_PROTECT_MASK="/etc/env.d /etc/gconf /etc/revdep-rebuild /etc/terminfo" CXXFLAGS="-march=k8 -O3 -pipe -fomit-frame-pointer" DISTDIR="/usr/portage/distfiles" FEATURES="autoaddcvs autoconfig ccache collision-protect distcc distlocks fixpackages metadata-transfer sandbox sfperms strict test userfetch userpriv usersandbox" GENTOO_MIRRORS="http://pandemonium.tiscali.de/pub/gentoo/ http://gentoo.ngi.it http://gentoo.intergenia.de http://ftp-stud.fht-esslingen.de/pub/Mirrors/gentoo/ http://linuv.uv.es/mirror/gentoo/ http://ftp.ntua.gr/pub/linux/gentoo/" LANG="it_IT.UTF-8" LC_ALL="it_IT.UTF-8" LINGUAS="it" MAKEOPTS="-j9" PKGDIR="/usr/portage/packages" PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress --force --whole-file --delete --delete-after --stats --timeout=180 --exclude='/distfiles' --exclude='/local' --exclude='/packages'" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/local/portage /usr/portage/local/layman/vmware" SYNC="rsync://rsync.gentoo.org/gentoo-portage" USE="amd64 X Xaw3d aalib acpi alsa arts audiofile avi bash-completion berkdb bitmap-fonts bzip2 cairo caps cdparanoia cdr cli crypt cups curl dbus dga dio dlloader dri dvd dvdr dvdread elibc_glibc emboss emul-linux-x86 encode exif expat fam fbcon ffmpeg fftw firefox flac foomaticdb fortran ftp gd ggi gif glut gmp gnutls gphoto2 gpm gstreamer gtk2 hal iconv idn ieee1394 imagemagick imlib input_devices_evdev input_devices_keyboard input_devices_mouse isdnlog java javascript jbig jikes jpeg jpeg2k kde kdeenablefinal kernel_linux lcms libcaca libg++ linguas_it lm_sensors mad maildir matroska memlimit mime mmap mng motif mozilla mp3 mpeg mpi ncurses nls nptl nptlonly nsplugin offensive ogg openal opengl oss pam pcre pdf pdflib perl png posix ppds pppd python qt3 quicktime readline recode reflection samba sasl sdl session sharedmem shorten sndfile sockets sox speex spell spl ssl svg symlink sysvipc tcl tcltk tcpd theora threads tidy tiff tk truetype truetype-fonts type1-fonts udev unicode usb userland_GNU vcd video_cards_radeon vorbis wmf xine xml xorg xosd xpm xv xvid zlib" Unset: CTARGET, EMERGE_DEFAULT_OPTS, INSTALL_MASK, LDFLAGS, PORTAGE_RSYNC_EXTRA_OPTS
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.
