[PyKDE] Trying to build PyKDE for KDE 3

[Alex Willmer]

On Thursday 13 June 2002 3:49 am, Jim Bublitz wrote:
> At this point I think there definitely is something else going on.
> I've had the RH install (after the version fix) verified, and
> another poster verified a Mandrake 8.2 install. The sequence of
> errors you're getting doesn't point to any particular code problems
> and looks more like a library version problem with something (but
> not the 3.0.1 stuff). You'd get these kinds of problems if, for
> example, you were linked to Qt1.4.2 instead of Qt3.0.4 (having done
> it myself).
>

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.

>
> I looked at the log file (thanks for posting it!), and don't see a
> problem. I'd suggest the following:
>
>
> 1. If you had sip/PyQt installed from Mandrake, get rid of them
> (rpm -e). I'm not sure which version they are - if they're pre-3.1,
> they have libsip in the wrong place (it should only exist in
> python/site-packages now - remove any other versions in /usr/lib,
> /usr/local/lib or where-ever). If that was the case, then download
> sip and PyQt 3.2.4 from riverbankcomputing.co.uk and
> rebuild/re-install. It might also be a good idea to clean all of
> the sip/PyQt/PyKDE stuff out of python/site-packages too - maybe
> look at libkdecore.la *first* (it's a text file) and see if there's
> anything unusual in there (wrong path to libs, etc) sip, PyQt and
> PyKDE all need to be 3.2.4 for KDE3.0.0.
>

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.

>
> 2. If the first step doesn't appear to be the problem, you might
> want to make sure you have a clean KDE install - check for KDE libs
> (other than symlinks) in /usr/lib and other locations other than
> /opt/kde3/lib. Also check for libqt and libqt-mt and look for
> multiple versions of those (for example libqt.so.2 and libqt.so.3).
> If you can, delete and re-install KDE (that's pretty messy on SuSE
> because their installer 'yast' depends on KDE - don't know about
> Mandrake). Will the PyQt examples run?
>

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.

>
> Again, the libkdecore.la file in site-packages might provide a hint.
> If a necessary lib (like libkdecore or libqt) turns up earlier in
> the search path than /opt/kde3/lib or /usr/lib/qt3, it'll get used
> instead - I've tried to order things to prevent that, but might not
> have eliminated all of the possibilities.
>

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.

>
> 3. Try a clean build of PyKDE - running './configure' again deletes
> everything and rebuilds from the ground up. I know it's a long
> compile - the next version will be faster, so you might want to wait
> for that. I don't think anything will change in the next version
> that will affect the problem you're having though. Restore all the
> stuff you commented out too (starting with kmutlipledrag.sip) - it
> should all work once the real problem is fixed.
>

Yep done that: rm -rf PyKDE-3.2.4; tar xzvf PyKDE-3.2.4-1.tar.gz 

>
> I've run into these kinds of problems on my own systems and they
> can be very frustrating. The fix is usually simple once you find
> the cause. I always appreciate it when people stick with it this
> far and am happy to provide any help I can. Personally I think it's
> worth it - I've been writing stuff for my own use with PyKDE the
> last few weeks and it's really been fun and productive too.

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-removed.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 ilbkdecore.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?

With Thanks

Alex
-- 
Alex Willmer
mailto:siu99aw at rdg.ac.uk