[PyKDE] Trying to build PyKDE for KDE 3
Jim Bublitz
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
> /usr/lib/python2.2/site-packages/libqtcmodulibqtcmodule-3.2.4.so
> checks out and reports libsip.so.9
> =>/usr/lib/python2.2/site-packages/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):
> http://www.alexwillmer.uklinux.net/pykde-make--kde2-libkdecore-rem
> oved.log
> http://www.alexwillmer.uklinux.net/pykde-notes--post-lib-fiddling.
> txt
>
> 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
> --with-kde-libraries=/opt/kde3/lib
> --with-kde-includes=/opt/kde3/include
> ...'. 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.
> AC_ARG_WITH(qt-dir,
> [ --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
> toolchains?
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
carefully)
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.
-OR-
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
configured.
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.
Jim
More information about the PyQt
mailing list