Q: Shared python extension module calling another shared library?

[Randall Hopper]

Tom Vrankar:
 |I've finally tried to write a python extension module, just for practice.
...
 |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
...
 |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. Is this a complication, or does dynamic linking make sure the
 |proper libraries satisfy unresolved globals in different C modules?
 |
 |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.

I'm no expert as I've only done this twice (one on three different UNIX
platforms).  I can't comment about the "using different C libs" issue as
it's not come up for me.

However I can give a word about cascading .so dependencies:

       python 
          -> dynamically links 'mywrappers.so'
               -> dynamically links 'mylib.so'
                     -> dynamically links its depends ('libc.so', etc.)

For this to work without hacks (e.g $LD_LIBRARY_PATH), the libraries each
have to have been compiled with the right RPATH (dynamic library search
path) so that the dynamic linker can locate an executable's or ashared
library's shared library dependencies.  

For example, mywrappers.so's RPATH needs to include a directory for where
mylib.so is going to be so it also can be found.

Most modern UNIX OSs support RPATH at compilation link-time.
Unfortunately, the ld linker flag used to specify it differs widely.

  SGI IRIX   : RPATH_FLAG   = "-rpath"
  Sun Solaris: RPATH_FLAG   = "-R"
  FreeBSD    : RPATH_FLAG   = "-rpath-link"
  DEC OSF1   : RPATH_FLAG   = "-rpath"

In my limited experience, DEC OSF1 is the only one of these four that
didn't seem to support RPATH specification in shared libraries for shared
library dependencies (in the OS version they're running here).  That is, in
this case:

    python -> A.so -> B.so

the dynamic linker couldn't find B.so, even though A.so's RPATH told it
where to look.  There, the $LD_LIBRARY_PATH hack is required.

Use a build production something like this:

  BUILD_SO  = $(LINK_SO) $(LDFLAGS) $(RPATH_FLAG) mylibdir \
                                    -Lmylibdir -lmylib

Unfortunately, LINK_SO varies from OS to OS also.  gcc -shared helps with
this if you can afford to use it.

 | From: no at spam.net (Tom Vrankar)

Consider a Yahoo web mail accont (http://mail.yahoo.com).  Free, works
well, and they run an open source OS.  If spam gets bad, change your user
name.  Works for me.

-- 
Randall Hopper
aa8vb at yahoo.com