[PyKDE] New PyKDE Release (alpha6) and Killing PyKDE 3.8

Simon Edwards simon at simonzone.com
Tue Apr 27 18:46:01 BST 2004


On Tuesday 27 April 2004 09:49, Jim Bublitz wrote:
> I'm not sure if this is the same situation (I think it is), but 
> what I did when I originally played around with this is to write 
> a module (.so) that KSpread would load and in turn that module 
> loaded libpythonize. The second load was done using 
> KLibLoader::globalLibrary (loading libpythonize linked with -Wl, 
> E), and that solved the problem.
>
> I believe it's the code *doing* the loading via dlopen that needs 
> RTLD_GLOBAL set, and that's what KLibLoader::globalLibrary does. 
> That would mean modifying the KDE loading code, not our libs, to 
> load in a "single stage" (ie libpythonize linked in, not loaded 
> in).

True. I didn't write that down explicitly as being the Right Way in my email, 
but yeah, you are right. :) I'm thinking of putting a Wish in KDE's bugzilla 
asking for RTLD_GLOBAL in kcontrol and kcmshell.

> David originally started with *no* libpythonize - he just added 
> the Python calls to his lib and linked in libpython.a. We 
> reorganized it to use libpythonize, but linked it rather than 
> explicitly loading it. Maybe trying to load it instead of 
> linking to it would be worth a try.

that is what I'm getting at. A two-stage loader.

> The other possibility is to try using libtool, but I don't know 
> enough about libtool to enjoy using it (or to know if it would 
> solve anything), and there are version problems with it.

I'm not sure if that will make a difference. libtool uses the same linkers and 
stuff that we're already using.

cheers,

-- 
Simon Edwards             | Guarddog Firewall
simon at simonzone.com       | http://www.simonzone.com/software/
Nijmegen, The Netherlands | "ZooTV? You made the right choice."




More information about the PyQt mailing list