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

[Simon Edwards]

On Sunday 25 April 2004 00:01, Jim Bublitz wrote:
> On Saturday April 24 2004 13:01, Simon Edwards wrote:
> > On Friday 23 April 2004 18:46, Jim Bublitz wrote:
> > > I have disowned libpythonize :) Who's going to be
> > > responsible for that is kind of up in the air at the moment.
> > I really need it, so it looks like I just got the job.
> Feel free to do anything you want with it - there isn't much to 
> it to begin with, and what little there is can probably be 
> organized better.

I've been working with libpythonize the last few days and I reakon I've 
figured out its "mysteries". You may or may not recall that for things like 
the Python kcontrol modules there was a problem with 'import'ing some 
modules. Namely the *.so for a module would not load into python when 
everything is embedded. You would get an annoying "Import Error: unable to 
resolve symbol PyFooBar" etc. David didn't know why that happened, but he had 
a workaround, link any module *.so files you need with the kcontrol stub 
(like /usr/lib/python2.3/dyn-load/time.so if needed the 'time' module). That 
worked, and you could import modules, but David didn't know why it worked.

Anyway, answer lies on the dlopen() man page:

    Optionally, RTLD_GLOBAL may be or'ed with flag,  in  which  case
    the  external  symbols defined in the library will be made available to
    subsequently loaded libraries.

When kcontrol loads a module, it uses dlopen() load in the our python stub. 
The stub loads and libpython gets pulled in too. Then later the python 
interpreter uses dlopen() too to load time.so (or some other module). Then it 
fails. The reason being that kcontrol does _not_ use RTLD_GLOBAL when opening 
our module stub, so libpython gets loaded but its symbols are _not_ made 
available to the next dlopen() call (the one for the module import). That is 
why an imported module can't resolve symbols from libpython.

Now, why does David's workaround actually work? When you link the kcontrol 
module stub against the time.so python module, the linker specifies in the 
generated module stub that time.so should also be loaded when loading the 
stub (along with libpython). So when kcontrol loads the stub, libpython gets 
pulled in and also time.so _at the same time_. And everything resolves 
correctly. Later python uses dlopen() to load time.so. dlopen() sees that 
time.so is already loaded and just happily goes on its merry way and life is 
good...

For bonus points: Is it possible to make a kcontrol module stub that loads 
libpythonize and libpython using dlopen(), but with the RTLD_GLOBAL flag set 
so that dlopen() in the python interpreter will work as expected? I guess 
I'll have to try that out... :-)

(BTW, linking with -export-dynamic -Wl,-E doesn't seem to have much effect)

cheers,

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