(There are distribution-specific notes at the end of this page)
Before each release, PyKDE is test built against SuSE, Red Hat and Mandrake Linux distributions, and various versions of Python, TQt 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):
The people on the PyKDE mailing list are knowledgeable about Python, PyTQt,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.
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:
python configure.py > output.txt
|
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.
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).
If you are reporting PyKDE run-time errors (not install errors), there's no need to include the configure.py output, but at a minimum you should indicate what PyKDE version the error occurred with and provide a small code sample that reproduces the error.
If you edit any of the sip files to repair bugs or modify PyKDE, you must 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.
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.
PyKDE attempts to identify gcc versions that have problems and select the correct mode automatically.
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:
> ImportError: /usr/lib/python2.2/site-packages/libtdecorecmodule.so:
> undefined symbol: _ZNK10TDEAboutData18copyrightStatementEv
|
You can decipher the mangled name to a class and method (in the example above, TDEAboutData::copyrightStatement) by running:
c++filt <symbolname>
for example:
c++filt _ZNK10TDEAboutData18copyrightStatementEv
|
If you can locate the sip file for the class, you can comment out ("//") the missing method, and recompile (including re-running configure.py. If you can't solve the problem (and even if you do) you should report it on the PyKDE mailing list at PyKDE@mats.imk.fraunhofer.de . Subscribe to the list
hereDuring 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:
1.Edit (as root) /etc/ld.so.conf from this:
/opt/kde
/opt/kde2
/opt/trinity
|
to this:
/opt/trinity
/opt/kde
/opt/kde2
|
2. Run (as root) ldconfig
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.
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.
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.
To fix this problem, all versions of the setShared method should be commented out in kfileshare.sip.
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.
The following exchange is from the PyKDE mailing list. The reply is from Simon Edwards:
> 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/libtdecorecmodule.so:
> undefined symbol: _ZNK10TDEAboutData18copyrightStatementEv
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:
http://plf.zarb.org/~nanardon/urpmiweb.php
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. :-)
|
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.