[PyKDE] Trying to build PyKDE for KDE 3
jbublitz at nwinternet.com
Sun Jun 16 22:48:00 BST 2002
On 16-Jun-02 Alex Willmer wrote:
> On Thursday 13 June 2002 3:49 am, Jim Bublitz wrote:
> Yes, I was (accidently) using the QT 3.0.2 version of PyQT with
> QT 3.0.4, now fixed and PyQT has been rebuilt. Thankyou for
> pointing me to that one.
> No old rpms were installed (I madde sure of that from the start),
> but there were some pieces from an old version of sip hanging
> around in /usr/local, should have checked for that before. All
> three installed versions of sip, PyQT and PyKDE (well, partial)
> are now most definitely version 3.2.4 or greater.
> I have on my machine, dual installs of qt & kde. KDE 2.2.2 is
> installed with /usr/ prefix, and uses QT 2.3.1 installed at
> /usr/lib/qt2/. KDE 3.0.0 is installed with /opt/kde3/ as
> prefix, and uses QT 3.0.4 installed at /usr/lib/qt3/. I should
> perhaps have made this clearer earlier.
> There are no other versions of QT or KDE, even in source form
> outside of my home dir. The PyQT examples do run, including the
> multi threaded ones (eg semaphore.py, & tut14.py). ldd of
> checks out and reports libsip.so.9
> I had already tried reinstalling KDE from the Mandrake rpms, I
> don't really wan't to compile the whole thing from source,
> although I could if it were necessary.
> My guess is somthing along these lines is happening, I've been
> experimenting with /etc/ld.so.conf, and LD_LIBRARY_DIR and some
> lib fiddling. It would appear that PyKDE is trying very hard to
> link against (/usr/lib/)libkdecore.so.3. On my machine this is
> a KDE 2 library, and hence has symbols missing for PyKDE's
> purposes. On my machine the KDE 3 equivalent is
> /opt/kde3/lib/libkdecore.so.4, only by removing the KDE 2
> version, and symlinking the KDE 3 version to
> /opt/kde3/lib/libkdecore.so.3 can I get PyKDE to link
> libkdecore properly.
> Yep done that: rm -rf PyKDE-3.2.4; tar xzvf PyKDE-3.2.4-1.tar.gz
> Agree totally, that I'm still learning the ins and outs of Linux
> has hindered matters a bit, but I think progress is happening.
> I've posted new files at my website (warning make log is 500K):
> The gist is that by removing the kdecore libs from /usr/lib/ and
> making symlinks from the ones in /opt/kde3/lib/ make install
> successfully performs '/usr/bin/python -c "import kdecore"'.
> However something in the build system/my setup is overriding
> the './configure --with-kde-dir=/opt/kde3
> ...'. The make install step simply fails latter in another
> library, with similar symptoms.
> Currently I'm trying to work out what is forcing libkdecore.so.3
> to be selected exclusively (ie why make install complains about
> missing libkdecore when libkdecore.so.3 is removed but
> libkdecore.so.4 is present and in the search path). I was
> curious about these lines from configure.in[68:71]:
> dnl Use the KDE root directory if it was explicitly given.
> [ --with-kde-dir=DIR KDE root directory is DIR])
> I don't know the ins and outs of automake, but should that not be
> 'AC_ARG_WITH(kde-dir,' instead of qt-dir? I don't think this is
> the cause of my problem though, even _if_ it is wrong, it would
> appear that either (a) /usr/lib/ is used in preference to other
> directories, even when the are specified, or (b) somewhere
> libkdecore.so.3 is specifically requested over
> other versions, or (c) other. My current guess is (b), as it
> would be most consistant with what I've seen. But as always,
> (c) is very possible. Is there is a part of PyKDE/PyQT/sip
> that uses library versioning, or is it embedded in the gnu
Thanks again for putting this much effort in! Basically, everything
seems to point to the same set of problems now, and had I been
paying more attention at the beginning, I might have caught it more
quickly. It's basically a problem with library naming and
locations. For example, PyKDE looks for libkdecore.so, not so.X,
because PyKDE supports KDE 2.1.1->3.0.0. By specifying a specific
location for libkdecore (say /opt/kde3), you get a '-L/opt/kde3' in
the link search path.
Unfortunately though, the complete link search path looks like:
-L /usr/lib -L /opt/kde3
and if you have /usr/lib/libkdecore.so -> /opt/kde2/libkdecore.so.2
and /opt/kde3/libkdecore.so -> /opt/kde3/libkdecore.so.3, you will
always get the so.2 library, no matter what options you give to
configure. You're also correct about the 'kde-dir' bug in
configure, although I'm not sure it's a problem. The libsip stuff
hanging around in /usr/local may have been a problem too - either
for install or later at runtime.
The problem occurs in PyKDE because I develop on SuSE which doesn't
use /usr/lib for Qt/KDE libs, but Mandrake and RH do, and I still
have some problems in ordering the search path (I apparently fixed
PyKDE for Qt but not KDE, but looks like I should check both again
There are two things you can try:
1. Temporarily rename all KDE libs in /usr/lib. For example,
rename /usr/lib/libkdecore.so -> /usr/lib/zlibkdecore.so. You'll
need to do this for all variations of libDCOP, libkdecore,
libkdeui, libkio, libkfile, libkparts, libkhtml, libkjs, libkspell,
libkdeprint and libkdesu. Also in each of the subdirectories under
PyKDE-3.2.4 (dcop and k*) delete any lib* files and .libs
directories. Then re-run make - it should only re-link and not
recompile. After installing, restore the lib names in /usr/lib.
There may still be a problem at runtime however, depending on how
the paths are arranged in the *.la file in site-packages.
2. In each of the *.sip-in files in PyKDE-3.2.4/sip/kde30 (for
KDE3.0.0), find the *LIBADD line near the end (for example
libkdeuicmodule_la_LIBADD) and in those lines, move '-L$$(libdir)'
to the end of the list after all of the KDE libs/paths (watch out
for the '\' line continuations). In PyKDE-3.2.4/lib/configure.in.in
change 'qt-dir' to 'kde-dir' as above. Then ./configure;make. This
will rebuild everything. 'libdir' is /usr/lib. I don't think this
will cause any other problems and should fix the link path problems.
Looks like a lot of messing around either way :(
It should be possible to run KDE2.2.2 and KDE3.0.0 on the same
system, but PyKDE will only support one or the other as currently
As to the libkdecore.so.3/.so.4 problem, I'm not sure. Is there a
libkdecore.so symlink in the search path pointing to the so.4 lib?
Sorry you've had so much trouble - thanks again.
More information about the PyQt