1 |
"John P. Burkett" <burkett@×××.edu> posted 4A345D3B.9030704@×××.edu, |
2 |
excerpted below, on Sat, 13 Jun 2009 22:15:23 -0400: |
3 |
|
4 |
> Doing "emerge -NauvD world" on an amd64 machine today produced an error |
5 |
> message including the following lines: |
6 |
|
7 |
> /usr/qt/3/include/qimage.h:61: warning: suggest parentheses around && |
8 |
> within || |
9 |
> /bin/sh: line 3: 4627 Segmentation fault /usr/qt/3/bin/uic |
10 |
> -nounload -tr tr2i18n -i kshortcutdialog_advanced.h |
11 |
> ./kshortcutdialog_advanced.ui > kshortcutdialog_advanced.cpp.temp |
12 |
> make[3]: *** [kshortcutdialog_advanced.cpp] Error 139 |
13 |
> make[3]: *** Waiting for unfinished jobs.... |
14 |
|
15 |
That wasn't the first error, but the first one wasn't too far above that |
16 |
and was also a segfault. FWIW, searching the log for either "err" (case |
17 |
insensitive, this one will produce a lot of false positives, hitting on |
18 |
error functions in what what's being compiled, etc, but it's usually |
19 |
quite easy to tell the false positives from the error) or "Waiting for |
20 |
unfinished jobs" often makes finding the first error easier. |
21 |
|
22 |
Here it is, from your attached changelog (thanks): |
23 |
/usr/qt/3/bin/uic -nounload -tr tr2i18n -i kshortcutdialog_simple.h |
24 |
./kshortcutdialog_simple.ui > kshortcutdialog_simple.cpp.temp ; |
25 |
ret=$?; |
26 |
[snip] |
27 |
|
28 |
/bin/sh: line 3: 4547 Segmentation fault /usr/qt/3/bin/uic |
29 |
-nounload -tr tr2i18n -i kshortcutdialog_simple.h |
30 |
./kshortcutdialog_simple.ui > kshortcutdialog_simple.cpp.temp |
31 |
echo '#include <klocale.h>' >> kshortcutdialog_advanced.cpp |
32 |
make[3]: *** [kshortcutdialog_simple.cpp] Error 139 |
33 |
make[3]: *** Waiting for unfinished jobs.... |
34 |
|
35 |
Here's the directory it was working in (for both errors). That tends |
36 |
to help put the error(s) in context: |
37 |
|
38 |
> make[3]: Leaving directory |
39 |
> `/var/tmp/portage/kde-base/kdelibs-3.5.10-r6/work/kdelibs-3.5.10/kdeui' |
40 |
|
41 |
> I have tried re-emerging qt and inserting "kde-base/kdelibs utempter" in |
42 |
> the /etc/portage/package.use file. |
43 |
> Neither of those steps resolved the problem. |
44 |
|
45 |
Segfaults aren't supposed to happen during a build. When they do |
46 |
happen, it often indicates hardware issues, especially when it's |
47 |
gcc or the like segfaulting. However, here, it wasn't gcc, but |
48 |
"uic", and I don't know if it's generally as resistant to segfaulting. |
49 |
|
50 |
One often useful way to help figure out whether it's hardware or |
51 |
software is to run the compile again, and see if the error happens |
52 |
in the same or a different place. Setting MAKEOPTS=-j1 also |
53 |
helps with the ordering, so you're likely to get the same error |
54 |
at the same spot as a different -j1 run (tho generally not the same |
55 |
as when running multiple jobs, as you were here). That also forces |
56 |
everything to serialize, thus often making the error and reason for |
57 |
it clear. |
58 |
|
59 |
If with multiple -j1 runs it always segfaults in the same place, |
60 |
it's probably software. If it's segfaulting or otherwise erroring |
61 |
in different places each time, it's very likely hardware related. |
62 |
If it's hardware, you can often make it more reliable by |
63 |
underclocking memory and/or the CPU, if your BIOS allows that. |
64 |
(FWIW, I had some bad memory at one point. It would pass memtest, |
65 |
but in normal use it wasn't entirely reliable. Turns out it |
66 |
simply wasn't stable at the clock rate it was certified and the |
67 |
internal settings were set for. Reducing the clock rate one notch |
68 |
made it stable as a rock, even when I clawed back a bit of the lost |
69 |
performance with manual wait-state tuning. So I know what that's |
70 |
like, for sure! At other times I've had CPU issues (due to |
71 |
overclocking, something I've not done since I went 64-bit) and |
72 |
hard drive issues. Others have had issues due to underpowered |
73 |
or faulty power-supplies or UPS units.) |
74 |
|
75 |
Meanwhile, I don't know much about the internals of qt, but I'd guess |
76 |
"uic" indicates "UI compiler (where UI is of course user interface), |
77 |
particularly since dialogs are certainly UI elements and that's |
78 |
what it was working on. |
79 |
|
80 |
Actually, running /usr/qt/3/bin/uic (path as I have the qt4 |
81 |
version as well, ordered first in the path) with no options, |
82 |
it TELLS you what it is at the top of the help message it spits |
83 |
out: "Qt user interface compiler." So I guessed correctly! =:^) |
84 |
|
85 |
A quick equery belongs indeed says uic belongs to qt3 (with other |
86 |
versions elsewhere belonging to qt4 and PyQt4), so that's confirmed. |
87 |
|
88 |
You said you already tried remerging qt, which would have been my |
89 |
initial suggestion. Question: Are you sure you remerged qt3, |
90 |
*NOT* qt4? That's make a difference! =:^) Try emerge -1 qt:3 |
91 |
to remerge the slot 3 version, if you need to. |
92 |
|
93 |
Beyond that, I don't know... Let me check for bugs that look |
94 |
similar... Either there are none or my bug-foo is bad today. |
95 |
Thus, assuming you've double-checked that you were remerging |
96 |
qt3, and assuming two -j1 runs duplicate the error at exactly |
97 |
the same place, unless someone else happens to do better |
98 |
than I did, I'd say it's time to post a bug and let the |
99 |
Gentoo KDE/Qt devs at it. (Some read this list and may |
100 |
be able to help you here, but unless it's trivial or there's |
101 |
already a bug they can point you to, they'll probably want |
102 |
a bug anyway, as that's just how Gentoo devs seem to track |
103 |
/everything/, using bugs, even for stuff like dev-relations |
104 |
new-dev and dev-retirement bugs, which might initially seem |
105 |
unintuitive, but it works.) |
106 |
|
107 |
-- |
108 |
Duncan - List replies preferred. No HTML msgs. |
109 |
"Every nonfree program has a lord, a master -- |
110 |
and if you use the program, he is your master." Richard Stallman |