Q: Shared python extension module calling another shared library?

[John W. Stevens]

Tom Vrankar wrote:
> 
> I've finally tried to write a python extension module, just for practice. I
> understand the basics but am really not clear at all about which objects need
> me to call INCREF or DECREF, and which ones are already taken care of. I'll
> have to cruise the website some more to find a complete example.

INCREF and DECREF can be/should be called for specific reasons for all
objects.  The simplest way to explain it is to say: if you are storing a
reference to the object, INCREF the object.  When you remove or delete a
reference to an object, DECREF it.  I have a couple of C extension
modules that you could take a look at, if you want.  Two of 'em
implement container classes, so the proper use of
DECREF and INCREF is critical.  Send me an email if you want them.

> 
> But my first problem is linking libraries. I'm trying to write an extension
> module as a shared library on HP-UX using gcc that in turn calls another
> shared library that appears to be C++ based

Ouch!  A number of questions spring to mind: Did you export symbols from
all of your shared libraries?  How are you handling the name mangling
thing?  What kind of library structure are you tring to work with?

> My approach was to follow the cookbook as directed in the HTML documentation,
> using Misc/Modules.pre.in and Setup.in. A vanilla extension module worked fine
> (a function to return its arguments; yay!). I then wrote another to wrap the
> dfi. It calls dfi_version() in the shared dfi library -- which just returns a
> pointer to a string -- and added the gcc switches specified in Mentor's
> dfilink script for the default shared library. Although make returns
> successfully, import fails (but it's unhelpfully vague about what it doesn't
> like).

What does it say?


> I realize I don't completely understand all the nuances of shared libraries,
> particularly when I've got one calling another. And the dfi library uses a c++
> library that claims to override some of the standard C functions.

Whoa!  That may a problem.  The structure of your system, as well as the
visibility of the symbols in your libraries and the libraries you are
using is critical to figuring this out.

> Does anyone have any suggestions or tips on how to go about linking this mess
> together? Or how at least to debug whatever problem import has? Any help is
> appreciated.

Yeah.  More info on the structure, error messages, and symbol
import/export status is needed.  As a first hack at debugging this, you
might try coming up with a very simple C program that uses the shared
library functions to set up a test environment.  Look up and read, very
carefully, the shl_load function in the man pages.

============

If I spoke for HP --- there probably wouldn't BE an HP!

John Stevens
jstevens at basho.fc.hp.com