| Summary: | Emerging QT always breaks | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Fotios Lindiakos <fotios> |
| Component: | Current packages | Assignee: | Gentoo KDE team <kde> |
| Status: | RESOLVED INVALID | ||
| Severity: | normal | CC: | craig.lawson |
| Priority: | High | ||
| Version: | unspecified | ||
| Hardware: | x86 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
|
Description
Fotios Lindiakos
2004-04-07 14:30:47 UTC
I have the same problem. Same version of Qt. As per bug 46381, I reemerged gcc and glibc. However, I verified each installation first, and each had a number of failures. I am using prelink, and I thought prelink was supposed to patch the portage database to prevent MD5 errors? Anyway, I reemerged gcc and glibc. No joy. Same Qt emerge failures. # emerge info Portage 2.0.50-r3 (default-x86-1.4, gcc-3.3.2, glibc-2.3.2-r9, 2.4.25-gentoo) ================================================================= System uname: 2.4.25-gentoo i686 Intel(R) Pentium(R) 4 CPU 2.60GHz Gentoo Base System version 1.4.3.13 Autoconf: sys-devel/autoconf-2.58-r1 Automake: sys-devel/automake-1.8.3 ACCEPT_KEYWORDS="x86" AUTOCLEAN="yes" CFLAGS="-O3 -march=pentium4 -funroll-loops -fprefetch-loop-arrays -fomit-frame-pointer -pipe" CHOST="i686-pc-linux-gnu" COMPILER="gcc3" CONFIG_PROTECT="/etc /usr/X11R6/lib/X11/xkb /usr/kde/2/share/config /usr/kde/3/share/config /usr/share/config /var/qmail/control" CONFIG_PROTECT_MASK="/etc/gconf /etc/terminfo /etc/env.d" CXXFLAGS="-O3 -march=pentium4 -funroll-loops -fprefetch-loop-arrays -fomit-frame-pointer -pipe" DISTDIR="/usr/portage/distfiles" FEATURES="autoaddcvs ccache sandbox" GENTOO_MIRRORS="http://gentoo.seren.com/gentoo ftp://mirror.iawnet.sandia.gov/pub/gentoo/ http://cudlug.cudenver.edu/gentoo/ http://mirror.tucdemonic.org/gentoo/" MAKEOPTS="-j3" PKGDIR="/usr/portage/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/local/portage" SYNC="rsync://rsync.gentoo.org/gentoo-portage" USE="X alsa apm avi berkdb bonobo cdr crypt cups dga doc dvd dvdr emacs encode foomaticdb gdbm gif gnome gpm gtk gtk2 gtkhtml guile imlib jack java jikes jpeg libg++ libwww mad mikmod mmx motif mozilla mpeg mysql ncurses nls oggvorbis opengl oss pam pda pdflib perl png ppds python quicktime readline scanner sdl slang spell sse ssl tcltk tcpd tiff truetype usb video_cards_radeon videos x86 xml2 xmms xv zlib" Please both try to use CFLAGS="-O2 -march=?????? -pipe" only. It is more than likely that you hit a bug in gcc. Less optimization probably circumvents it. Qt doesn't use the end user's cflags settings for this very reason - very likely you hit a bug in gcc/glibc. Hey! It compiled! Soon after writing comment #1, I set up a repeating script and went to bed. Apart from the re-emerge of gcc and glibc I mentioned, I made no further changes to my system. Will the magic ever cease? Anyway, here's my script. It's low-tech yet persistent. while ! emerge --verbose --oneshot qt; do sleep 1m; done Very interesting. The fact that it worked for you in stages makes me believe your processor may be getting too hot during a compile? You may want to run a hard compile again like qt and monitor your processor temp with lm_sensors. Too hot? Interesting suggestion! I recompiled Qt to check it out. This time, the compilation succeeded the first time (duh, of course it did, because I watched it the whole time). My processor temperature quickly rose from 105F to 135.5F +/- 0.9, and stayed there for the duration. Which was about 30 minutes. While it's possible the temperature went higher last night, I doubt it because ambient conditions were no different (slightly cooler, if anything). While waiting for the compilation to fail, I came up with some reasons to doubt the temperature theory: * My kernel builds never fail and they take a long time, too (though not as long as Qt). * My processor is a Pentium 4, which I believe it has an internal temperature monitor that gradually throttles the processor clock during overheating. I don't know the trigger temperature, and I don't think I would know if it was doing this, but this mechanism is in place to prevent processor damage and, presumably, malfunction. * Other processes running on this system during the compilation, notably gkrellm, xmms, gnome, X, make, and the kernel, do not fail. Although one may presume that because the compiler takes most of the CPU time, it may be most likely to be affected by a processor malfunction, the other processes are never affected. (OK, the damage could be delayed, but it's 24 hours later and still no evidence). * Several months ago I had problems compiling large packages, and was advised that gcc has known problems. Qt is a better "testbed" for the compiler because the C++ is a lot more intensive to compile than straight C (like the kernel, or gnome type stuff). 135 doesn't sound all that hot for the processor. Could you possibly have a stick of ram with a bad area in it? Grasping for straws here, but I hear about this type of compilation failure a lot and it's usually either hardware problems, or a borked glibc/gcc. anyway, it's not a problem in the qt build so closing bug. I agree. "Emerging QT sometimes breaks" would be more accurate. I had my memory POST disabled, and reenabled it yesterday to see if I had bad RAM. I don't. (But why would it affect only gcc and not linking, other programs, or file and disk buffering, or other kernel activities?) I think you are on to something in Comment #7 when you comment that C++ is a lot more intensive, and the kernel doesn't use it. A completely reasonable explanation is that gcc has some uninitialized memory which QT tickles and most other code doesn't. Uninitialized memory bugs sometimes fail and sometimes don't, are easy to introduce to code, and this is exactly the behavior described. |
