"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, as that's just how Gentoo devs seem to track
/everything/, using bugs, even for stuff like dev-relations
new-dev and dev-retirement bugs, which might initially seem
unintuitive, but it works.)
--
Duncan - List replies preferred. No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master." Richard Stallman
