[gentoo-amd64] Re: kdelibs-3.5.10-r6 failed
John P. Burkett burk...@uri.edu posted 4a345d3b.9030...@uri.edu, excerpted below, on Sat, 13 Jun 2009 22:15:23 -0400: Doing emerge -NauvD world on an amd64 machine today produced an error message including the following lines: /usr/qt/3/include/qimage.h:61: warning: suggest parentheses around within || /bin/sh: line 3: 4627 Segmentation fault /usr/qt/3/bin/uic -nounload -tr tr2i18n -i kshortcutdialog_advanced.h ./kshortcutdialog_advanced.ui kshortcutdialog_advanced.cpp.temp make[3]: *** [kshortcutdialog_advanced.cpp] Error 139 make[3]: *** Waiting for unfinished jobs That wasn't the first error, but the first one wasn't too far above that and was also a segfault. FWIW, searching the log for either err (case insensitive, this one will produce a lot of false positives, hitting on error functions in what what's being compiled, etc, but it's usually quite easy to tell the false positives from the error) or Waiting for unfinished jobs often makes finding the first error easier. Here it is, from your attached changelog (thanks): /usr/qt/3/bin/uic -nounload -tr tr2i18n -i kshortcutdialog_simple.h ./kshortcutdialog_simple.ui kshortcutdialog_simple.cpp.temp ; ret=$?; [snip] /bin/sh: line 3: 4547 Segmentation fault /usr/qt/3/bin/uic -nounload -tr tr2i18n -i kshortcutdialog_simple.h ./kshortcutdialog_simple.ui kshortcutdialog_simple.cpp.temp echo '#include klocale.h' kshortcutdialog_advanced.cpp make[3]: *** [kshortcutdialog_simple.cpp] Error 139 make[3]: *** Waiting for unfinished jobs Here's the directory it was working in (for both errors). That tends to help put the error(s) in context: make[3]: Leaving directory `/var/tmp/portage/kde-base/kdelibs-3.5.10-r6/work/kdelibs-3.5.10/kdeui' I have tried re-emerging qt and inserting kde-base/kdelibs utempter in the /etc/portage/package.use file. Neither of those steps resolved the problem. Segfaults aren't supposed to happen during a build. When they do happen, it often indicates hardware issues, especially when it's gcc or the like segfaulting. However, here, it wasn't gcc, but uic, and I don't know if it's generally as resistant to segfaulting. One often useful way to help figure out whether it's hardware or software is to run the compile again, and see if the error happens in the same or a different place. Setting MAKEOPTS=-j1 also helps with the ordering, so you're likely to get the same error at the same spot as a different -j1 run (tho generally not the same as when running multiple jobs, as you were here). That also forces everything to serialize, thus often making the error and reason for it clear. If with multiple -j1 runs it always segfaults in the same place, it's probably software. If it's segfaulting or otherwise erroring in different places each time, it's very likely hardware related. If it's hardware, you can often make it more reliable by underclocking memory and/or the CPU, if your BIOS allows that. (FWIW, I had some bad memory at one point. It would pass memtest, but in normal use it wasn't entirely reliable. Turns out it simply wasn't stable at the clock rate it was certified and the internal settings were set for. Reducing the clock rate one notch made it stable as a rock, even when I clawed back a bit of the lost performance with manual wait-state tuning. So I know what that's like, for sure! At other times I've had CPU issues (due to overclocking, something I've not done since I went 64-bit) and hard drive issues. Others have had issues due to underpowered or faulty power-supplies or UPS units.) Meanwhile, I don't know much about the internals of qt, but I'd guess uic indicates UI compiler (where UI is of course user interface), particularly since dialogs are certainly UI elements and that's what it was working on. Actually, running /usr/qt/3/bin/uic (path as I have the qt4 version as well, ordered first in the path) with no options, it TELLS you what it is at the top of the help message it spits out: Qt user interface compiler. So I guessed correctly! =:^) A quick equery belongs indeed says uic belongs to qt3 (with other versions elsewhere belonging to qt4 and PyQt4), so that's confirmed. You said you already tried remerging qt, which would have been my initial suggestion. Question: Are you sure you remerged qt3, *NOT* qt4? That's make a difference! =:^) Try emerge -1 qt:3 to remerge the slot 3 version, if you need to. Beyond that, I don't know... Let me check for bugs that look similar... Either there are none or my bug-foo is bad today. Thus, assuming you've double-checked that you were remerging qt3, and assuming two -j1 runs duplicate the error at exactly the same place, unless someone else happens to do better than I did, I'd say it's time to post a bug and let the Gentoo KDE/Qt devs at it. (Some read this list and may be able to help you here, but unless it's trivial or there's already a bug they can point you to, they'll probably want a bug anyway,
Re: [gentoo-amd64] Re: kdelibs-3.5.10-r6 failed
Duncan pisze: Here it is, from your attached changelog (thanks): /usr/qt/3/bin/uic -nounload -tr tr2i18n -i kshortcutdialog_simple.h ./kshortcutdialog_simple.ui kshortcutdialog_simple.cpp.temp ; ret=$?; [snip] /bin/sh: line 3: 4547 Segmentation fault /usr/qt/3/bin/uic -nounload -tr tr2i18n -i kshortcutdialog_simple.h ./kshortcutdialog_simple.ui kshortcutdialog_simple.cpp.temp echo '#include klocale.h' kshortcutdialog_advanced.cpp make[3]: *** [kshortcutdialog_simple.cpp] Error 139 make[3]: *** Waiting for unfinished jobs I had problems with uic segmentation faults because I had march=native in my C/CXX FLAGS. When I changed native to k8 ( as in http://en.gentoo-wiki.com/wiki/Safe_Cflags/AMD ). Also I got an explanation ( http://forums.gentoo.org/viewtopic-p-5795915.html#5795915 ) that it's because qt3 is stripping flags. Some that must be compiled with the same flags as qt don't strip flags. So the are compiled with different flags.
Re: [gentoo-amd64] Re: kdelibs-3.5.10-r6 failed
Joachim pisze: Duncan pisze: Here it is, from your attached changelog (thanks): /usr/qt/3/bin/uic -nounload -tr tr2i18n -i kshortcutdialog_simple.h ./kshortcutdialog_simple.ui kshortcutdialog_simple.cpp.temp ; ret=$?; [snip] /bin/sh: line 3: 4547 Segmentation fault /usr/qt/3/bin/uic -nounload -tr tr2i18n -i kshortcutdialog_simple.h ./kshortcutdialog_simple.ui kshortcutdialog_simple.cpp.temp echo '#include klocale.h' kshortcutdialog_advanced.cpp make[3]: *** [kshortcutdialog_simple.cpp] Error 139 make[3]: *** Waiting for unfinished jobs I sent before I finished writing. Here is what I wanted to write: I had problems with uic segmentation faults because I had march=native in my C/CXX FLAGS. When I changing march=native to march=k8 ( as in http://en.gentoo-wiki.com/wiki/Safe_Cflags/AMD ) and reemerging qt-3 and kdelibs solved my problem. Also I got an explanation ( http://forums.gentoo.org/viewtopic-p-5795915.html#5795915 ): qt3 is stripping flags. Some that must be compiled with the same flags as qt don't strip flags. So the are compiled with different flags. So they don't work properly.
Re: [gentoo-amd64] Re: kdelibs-3.5.10-r6 failed
Joachim wrote:
Joachim pisze:
Duncan pisze:
Here it is, from your attached changelog (thanks):
/usr/qt/3/bin/uic -nounload -tr tr2i18n -i kshortcutdialog_simple.h
./kshortcutdialog_simple.ui kshortcutdialog_simple.cpp.temp ;
ret=$?;
[snip]
/bin/sh: line 3: 4547 Segmentation fault /usr/qt/3/bin/uic
-nounload -tr tr2i18n -i kshortcutdialog_simple.h
./kshortcutdialog_simple.ui kshortcutdialog_simple.cpp.temp
echo '#include klocale.h' kshortcutdialog_advanced.cpp
make[3]: *** [kshortcutdialog_simple.cpp] Error 139
make[3]: *** Waiting for unfinished jobs
I sent before I finished writing. Here is what I wanted to write:
I had problems with uic segmentation faults because I had march=native
in my C/CXX FLAGS. When I changing march=native to march=k8 ( as in
http://en.gentoo-wiki.com/wiki/Safe_Cflags/AMD ) and reemerging qt-3 and
kdelibs solved my problem.
Also I got an explanation (
http://forums.gentoo.org/viewtopic-p-5795915.html#5795915 ):
qt3 is stripping flags. Some that must be compiled with the same flags
as qt don't strip flags. So the are compiled with different flags. So
they don't work properly.
Thank you, Joachim, for your insights. Having no experience with
changing CFLAGS and CXXFLAGS, I should proceed cautiously.
Doing locate make.conf generates a long list of such files in various
directories. Guessing that /etc/make.conf may be the pertinent one, see
that its first 6 lines read as follows:
# These settings were set by the catalyst build script that
automatically built this stage
# Please consult /etc/make.conf.example for a more detailed example
CFLAGS=-Os -march=opteron -mtune=opteron -fomit-frame-pointer -ggdb
CHOST=x86_64-pc-linux-gnu
CXXFLAGS=${CFLAGS}
The question now, I suppose, is whether -march=opteron is safe for my
cpu. My /proc/cpuinfo file contains the following lines
vendor_id : AuthenticAMD
cpu family : 15
model : 65
model name : Dual-Core AMD Opteron(tm) Processor 2210
stepping: 2
The Safe Cflags/AMD web page you cited has a section on 22xx
Dual-Core Opteron consisting of 3 boxes. The first box consists of the
following lines:
vendor_id : AuthenticAMD
cpu family : 15
model : 65
model name : Dual-Core AMD Opteron(tm) Processor 22xx
stepping : 2
That closely matches my cpuinfo.
The second box consists of these lines:
CHOST=x86_64-pc-linux-gnu
CFLAGS=-march=opteron -O2 -pipe
CXXFLAGS=${CFLAGS}
Thus my -march=opteron setting seems safe. Are the discrepancies in
other parts of the CFLAGS line significant for my kdelibs problem?
Is there anything in the third box under 22xx Dual-Core Opteron that
needs attention?
-John
--
John P. Burkett
Department of Economics
University of Rhode Island
Kingston, RI 02881-0808
USA
phone (401) 874-9195
