[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