1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
|
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN
"http://www.w3.org/TR/html4/loose.dtd"">
<html>
<head>
<title>Troubleshooting</title>
<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
<meta name="GENERATOR" content="Quanta Plus">
</head>
<body>
<DIV
CLASS="NAVHEADER"
><TABLE SUMMARY="Header navigation table" WIDTH="100%" BORDER="0" CELLPADDING="0" CELLSPACING="0">
<TR><TH COLSPAN="3" ALIGN="center">Python Bindings for KDE (PyKDE-3.16.0)</TH></TR>
<TR><TD WIDTH="10%" ALIGN="left" VALIGN="bottom"><A HREF="install.html" ACCESSKEY="P">Prev</A></TD>
<TD WIDTH="80%" ALIGN="center" VALIGN="bottom"></TD>
<TD WIDTH="10%" ALIGN="right" VALIGN="bottom"><A HREF="switches.html" ACCESSKEY="N">Next</A></TD>
</TR>
</TABLE><HR ALIGN="LEFT" WIDTH="100%"></DIV>
<h1>Troubleshooting</h1>
<h2>Introduction</h2>
<p>
(There are distribution-specific notes at the end of this page)
</p>
<p>
Before each release, PyKDE is test built against SuSE, Red Hat and Mandrake Linux distributions,
and various versions of Python, Qt and KDE. Even after performing test builds, errors still can
occur with your installation. The most common sources of errors are (roughly in order of occurance):
</p>
<ul>
<li>Differences in user environments</li>
<li>Differences between distributions (or even between different builds of same version of the same distribution</li>
<li>Bugs - in PyKDE or any of the software it's based on (KDE, Qt, PyQt, sip, or even Python)</li>
</ul>
<h2>Reporting errors -- PLEASE READ!</h2>
<p>
The people on the PyKDE mailing list are knowledgeable about Python, PyQt,and PyKDE and are
genuinely helpful. You shouldn't hesitate to post a question or problem there (you may hear
"RTFM" occasionally, but not often). Chances are that someone using your distribution is already
posting to the list.
</p>
<p>
The most important thing you can do when reporting an installation error is to include the
configure.py output with your question, including the error message at the point of failure.
All configure.py messages write to stdout, so if you can't cut and paste the output, you can do:
</p>
<table border="0" bgcolor="#E0E0E0" width="100%">
<tr>
<td>
<pre CLASS="PROGRAMLISTING">
python configure.py > output.txt
</pre>
</td>
</tr>
</table>
<p>
to capture the output and attach the file to your post. In many cases, if you don't include
this info, the first response to your question will be to ask for the configure.py output. Including
it with your original post will save several hours or days in the process of obtaining an answer.
</p>
<p>
Bug reports are a vital part of any software development process. We generally try to provide
an immediate fix or work-around for problems reported, and then incorporate the fix into
future releases. Bug reports are always welcome (and always embarrassing).
</p>
<p>
If you are reporting PyKDE run-time errors (not install errors), there's no need to include
the configure.py output, but <b>at a minimum</b> you should indicate what PyKDE version the error
occurred with and provide a <i>small</i> code sample that reproduces the error.
</p>
<h2>If you perform repairs ...</h2>
<p>
If you edit any of the sip files to repair bugs or modify PyKDE, you <b>must</b> re-run
configure.py. configure.py includes code that generates the actual C++ code that compiles to PyKDE.
If you don't re-run configure.py, changes to the sip files will have no effect.
</p>
<h2>configure.py and make errors</h2>
<dl>
<dt>"Can't find a file or directory"</dt>
<dd>
configure.py first checks to make sure that it can locate and access all of the components PyKDE
depends on. If the directories or files aren't where configure.py thinks they should be, an error
will result and configure.py will exit. Usually these kinds of problems can be solved by adding
command line switches when running configure.py - see the <a href="switches.html">next page</a> for
the available command line options
</dd>
<dt>"Can't write ..." or "Can't create ..."</dt>
<dd>
build.py creates a number of directories and generates Makefiles and a lot of C++ code
(customized for your system). If the user running build.py doesn't have write access to
the directories where PyKDE sources were installed, the build will fail. You need to either
obtain write access, relocate PyKDE someplace where you have write access or (worst choice)
build PyKDE as root.
</dd>
<dt>"Can't remove or create directory"</dt>
<dd>
This happens rarely, but is a quirk of the PyKDE build process. PyKDE will build and make
as an unprivileged user BUT if you did a build of PyKDE previously as root and then attempt
to build PyKDE again as a user, the build will fail. The reason is that configure.py creates a
number of directories and a lot of files. The next time configure.py runs, it will try to delete
these directories and files before re-creating them. If the original directories and files
were owned by root, a user will be unable to delete them and configure.py will fail if run as
a user in that case.
</dd>
<dt>"Can't find PyQt sip files"</dt>
<dd>
You did install them, right? If you build PyQt from sources, the sip files will be there
somewhere (by default, PyQt installs the PyQt sip files in /usr/share/PyQt if built from
source). When you find them, you can tell configure.py where they are with a switch (see
<a href="switches.html">next page</a>). If you installed PyQt from RPMs (either downloaded or
from your distribution), the sip files are usually in a "devel" RPM for PyQt, which also needs
to be installed if you want to build PyKDE from sources.
</dd>
<dt>Code generation errors</dt>
<dd>
The PyKDE sources are mostly "sip" files which describe the interface to KDE's C++ libraries
to the sip code generator. These files should be error free. If a sip or code generation error occurs,
please report it to the PyKDE mailing list at <A HREF="mailto:[email protected]">
[email protected] </A> Subscribe to the list
<a href="http://mats.imk.fraunhofer.de/mailman/listinfo/pykde">here</a>
</dd>
<dt>Compile errors</dt>
<dd>
PyKDE should not experience any compile errors. Currently sip 4.0 based compiles will
generate a number of warnings - these can be safely ignored. If errors occur, please report them
to the PyKDE mailing list at <A HREF="mailto:[email protected]"> [email protected] </A>.
Subscribe to the list <a href="http://mats.imk.fraunhofer.de/mailman/listinfo/pykde">here</a>
</dd>
</dl>
<h2>Compile-time errors</h2>
<p>
PyKDE takes a long time to compile on some hardware, however no single module should take more than 25-30
minutes on any but the slowest hardware. Some gcc versions (for example gcc 4.0.1 on SuSE 10) will hang
if PyKDE C++ files have been generated in "concatenated" mode (see Installation and Switches pages for
more info). If you are using concatenated mode (each module consists of a single large file, instead of
many small files) and PyKDE's compilation hangs, re-run configure.py with the -i switch, then re-run make.
</p>
<p>
PyKDE attempts to identify gcc versions that have problems and select the correct mode automatically.
</p>
<h2>Run-time errors</h2>
<dl>
<dt>importTest.py errors</dt>
<dd>
<p>
All that importTest.py does is try to import each of the PyKDE modules. The most common error that
occurs when running importTest.py is that an unresolved symbol in one of the modules prevents the
module from loading. This can occur because not all KDE library versions contain all of the "official" KDE
classes and members. Although it doesn't occur often, 1 missing method (out of over 10,000) will
prevent a module from loading, and also prevent other modules that depend on the failing module
from loading. The error message will normally print a "mangled" version of the missing method's name:
</p>
<table border="0" width="100%">
<tr>
<td>
<pre CLASS="PROGRAMLISTING">
> ImportError: /usr/lib/python2.2/site-packages/libkdecorecmodule.so:
> undefined symbol: _ZNK10KAboutData18copyrightStatementEv
</pre>
</td>
</tr>
</table>
<p>
You can decipher the mangled name to a class and method (in the example above,
KAboutData::copyrightStatement) by running:
</p>
<table border="0" width="100%">
<tr>
<td>
<pre CLASS="PROGRAMLISTING">
c++filt <symbolname>
for example:
c++filt _ZNK10KAboutData18copyrightStatementEv
</pre>
</td>
</tr>
</table>
<p>
If you can locate the sip file for the class, you can comment out ("//") the missing method, and recompile
(including re-running <i>configure.py</i>. If you can't solve the problem (and even if you do) you should
report it on the PyKDE mailing list at <A HREF="mailto:[email protected]">
[email protected] </A>. Subscribe to the list
</p>
<a href="http://mats.imk.fraunhofer.de/mailman/listinfo/pykde">here</a>
</dd>
<dt>Other run-time errors</dt>
<dd>
At present only the most likely failure modes of PyKDE are tested (contributions of tests/test code
are greatly appreciated). Nearly all of PyKDE is completely machine generated from the KDE h files,
so coding errors are rare but they do happen. PyKDE also uses some classes and methods differently
because it's running from Python and not C++. If you suspect an error, please double-check your
code and review the PyKDE docs to be sure the argument lists and expected return types are what you
thought they were. If the problem persists, report it to the PyKDE mailing list at
<A HREF="mailto:[email protected]"> [email protected] </A>. Subscribe to the list
<a href="http://mats.imk.fraunhofer.de/mailman/listinfo/pykde">here</a>. <b>When reporting errors to the
list, it's always helpful if you provide:</b>
<ul>
<li>
the version of PyKDE you're using
</li>
<li>
a <i>small</i> sample of code that produces the problem.
</li>
</ul>
It's not particularly important whether the error is a PyKDE error or a user error (although
I prefer seeing user errors rather than my own).
</dd>
</dl>
<h2>Distribution-specific Notes</h2>
<h3>SuSE 8.0/8.1</h3>
<p>
During testing of PyKDE for KDE 3.x.x on SuSE 8.0 and 8.1 I
ran into problems with the kjs module insisting on linking to
the KDE2 version of libkjs.so instead of the KDE3. The lib
name/version is the same in both cases, but the libs aren't
compatible. The only solution I found was to:
</p>
<p>
1.Edit (as root) /etc/ld.so.conf from this:
</p>
<table border="0" bgcolor="#E0E0E0" width="100%">
<tr>
<td>
<pre CLASS="PROGRAMLISTING">
/opt/kde
/opt/kde2
/opt/kde3
</pre>
</td>
</tr>
</table>
<p>
to this:
</p>
<table border="0" bgcolor="#E0E0E0" width="100%">
<tr>
<td>
<pre CLASS="PROGRAMLISTING">
/opt/kde3
/opt/kde
/opt/kde2
</pre>
</td>
</tr>
</table>
<p>
2. Run (as root) ldconfig
</p>
<p>
3. Re-link. You can save having to rebuild PyKDE and recompile
by simply going into the PyKDE-3.x.x/kjs directory and deleteing
kjshuge.o (or any *.o in the directory) and then rerunning make
and make install (this forces a recompile/relink of the kjs module
only, which is very fast) Don't run configure.py before trying this,
or everything will recompile.
</p>
<p>
Alternatively, if you don't plan on using kjs, you can simply
ignore the fact that it's mis-linked - it won't affect any
other module.
</p>
<h3>SuSE 8.2/9.0</h3>
<p>
Some (but by no means all) versions of the KDE rpms for recent SuSE distributions appear
to have been built with a different version of kfileshare.h than what they ship with. This
version is also in disagreement with the "official" KDE version (as found in the kdelib
source files on kde.org, for example). The "incorrect" versions use a setShared(...) method
with a different argument list that doesn't match the h files.
</p>
<p>
To fix this problem, all versions of the setShared method should be commented out in
kfileshare.sip.
</p>
<h3>Mandrake 9.1</h3><h4>(rpm install - PyKDE-3.8, not 3.11 so far)</h4>
<p>
Some people have had trouble with the Mandrake 9.1 rpms/KDE libs. All
distributions modify KDE in some way and where feasible, PyKDE is
set up to build with the least common denominator.
</p>
<p>
The following exchange is from the PyKDE mailing list. The reply is
from Simon Edwards:
</p>
<table border="0" width="100%">
<tr>
<td>
<pre CLASS="PROGRAMLISTING">
> I'm trying to setup PyKDE on my Mandrake 9.1/python 2.2 box but so far I
> ImportError: /usr/lib/python2.2/site-packages/libkdecorecmodule.so:
> undefined symbol: _ZNK10KAboutData18copyrightStatementEv
Let me guess. You are using the original KDE version that came with Mandrake
9.1. :) yeah, there is a problem and the PyKDE rpms for mandrake don't work
with that version.
What you can do is update your KDE to 3.1.4. That should work. I'm using 3.1.2
here. You can go here:
<a href="http://plf.zarb.org/~nanardon/urpmiweb.php"> http://plf.zarb.org/~nanardon/urpmiweb.php</a>
and follow the directions and remember to select 'Texstar'. Now you will be
able to upgrade KDE using the Mandrake Install tool. Open up the Mandrake
Control Center and go to Install Software, do a search on "kde" and you
should get a big long list of KDE packages. Select the 3.1.4-tex2 ones and
when you are ready hit 'install'. and wait, and wait. :-)
</pre>
</td>
</tr>
</table>
<p>
</p>
<h3>Mandrake 10.x</h3>
<p>
Some people have had trouble compiling with Mandrake 10.x. Mandrake provides a few "non-standard"
h files. This only affects 3 or 4 methods, but is enough to prevent PyKDE from building. PyKDE 4.0
includes patches that should eliminate this problem.
</p>
<DIV CLASS="NAVFOOTER">
<HR ALIGN="LEFT" WIDTH="100%">
<TABLE SUMMARY="Footer navigation table" WIDTH="100%" BORDER="0" CELLPADDING="0" CELLSPACING="0" >
<TR>
<TD WIDTH="33%" ALIGN="left" VALIGN="top"><A HREF="install.html" ACCESSKEY="P">Prev</A></TD>
<TD WIDTH="34%" ALIGN="center" VALIGN="top"><A HREF="index.html" ACCESSKEY="H">Home</A></TD>
<TD WIDTH="33%" ALIGN="right" VALIGN="top"><A HREF="switches.html" ACCESSKEY="N">Next</A></TD>
</TR>
<TR>
<TD WIDTH="33%" ALIGN="left" VALIGN="top">Installation</TD>
<TD WIDTH="34%" ALIGN="center" VALIGN="top"> </TD>
<TD WIDTH="33%" ALIGN="right" VALIGN="top">build.py Options</TD>
</TR>
</TABLE>
</DIV>
</body>
</html>
|
