You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
pytde/doc/trouble.html

338 lines
14 KiB

<!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">
&gt; ImportError: /usr/lib/python2.2/site-packages/libkdecorecmodule.so:
&gt; 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 &lt;symbolname&gt;
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/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">
&gt; I'm trying to setup PyKDE on my Mandrake 9.1/python 2.2 box but so far I
&gt; ImportError: /usr/lib/python2.2/site-packages/libkdecorecmodule.so:
&gt; 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">&nbsp;</TD>
<TD WIDTH="33%" ALIGN="right" VALIGN="top">build.py Options</TD>
</TR>
</TABLE>
</DIV>
</body>
</html>