|
|
|
|
<!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:PyKDE@mats.imk.fraunhofer.de">
|
|
|
|
|
PyKDE@mats.imk.fraunhofer.de </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:PyKDE@mats.imk.fraunhofer.de"> PyKDE@mats.imk.fraunhofer.de </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:PyKDE@mats.imk.fraunhofer.de">
|
|
|
|
|
PyKDE@mats.imk.fraunhofer.de </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:PyKDE@mats.imk.fraunhofer.de"> PyKDE@mats.imk.fraunhofer.de </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/trinity
|
|
|
|
|
</pre>
|
|
|
|
|
</td>
|
|
|
|
|
</tr>
|
|
|
|
|
</table>
|
|
|
|
|
<p>
|
|
|
|
|
to this:
|
|
|
|
|
</p>
|
|
|
|
|
<table border="0" bgcolor="#E0E0E0" width="100%">
|
|
|
|
|
<tr>
|
|
|
|
|
<td>
|
|
|
|
|
<pre CLASS="PROGRAMLISTING">
|
|
|
|
|
/opt/trinity
|
|
|
|
|
/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>
|
