<!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/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>