[Swig] Python/SWIG: Namespace collisions in multiple modules.

[David M. Beazley]

Jakob Schiotz writes:
 > Dear Python and SWIG gurus,
 > 
 > 
 > I am converting many of my C programs to Python modules using SWIG,
 > and am having two related problems.
 > 
 > 1) How do I prevent namespace collisions if several modules contain
 > functions with the same name?
 > 

Hmmm.  As far as I know, there are no namespace collisions between
C modules provided they are compiled as separate shared libraries
and loaded dynamically.  Of course, this might be platform dependent.

 > 2) If the Python executable and several extension modules are using
 > the same library, how do I make sure they do not get separate copies
 > of it?  The library is apparently using global data.
 > 

You will need to look into magic linker options and chapter 12 of the
SWIG docs to make this work.  However, the gist of the solution is
that you need to make sure you link all of the extension modules
against a shared library, that you use the SWIG runtime libraries,
and that you use the -R or -rpath option (depends on the linker,
platform, etc...).   There are some examples of this in the docs and
in some of the tutorials I've given on SWIG.
 > 
 > Ad 2:
 > 
 > I am having problems with the MPI library (Message Passing Interface,
 > a library for parallel programming).
 > 
 > There is a complication with the this library: the initialization
 > function MPI_Init(&argc, &argv) MUST be called before the program
 > looks at its arguments.  This means that it cannot be done in a module
 > imported by a Python script, as the python executable has to look at
 > its arguments to figure out what script to load.  I have built a
 > modified Python executable which calls MPI_Init() just before calling
 > Py_Main(argc, argv).
 > 

This is what I've had to do with MPI in my own applications as well.

 > This works on the Compaq Alpha machines, and it worked under a
 > previous version of AIX, but with the new version of AIX (and a new
 > version of the MPI library) the extension module and the python
 > executable apparently get completely distinct versions of the MPI
 > library, so the extension module believes that MPI has not been
 > initialized, and crashes.  Any suggestions?  Can I somehow load the
 > entire MPI library into the Python executable and somehow be sure that
 > it is not linked into the extension modules as well?
 
It might be possible to add libmpi.a to the link line that builds
the Python executable (although you will probably just want to
list it as libmpi.a not as -lmpi).   Then make sure you link Python
so that it exports all of its symbols (including MPIs).

I know in our own application, the way that we solved this was to
write our own abstract message passing interface that could be
built on top of MPI or other similar libraries.  We then compiled
various versions of Python that included our special message 
passing API functions.   Then, we built extension modules using
only our custom API.   This worked particularly well because we
could just swap versions of Python to change message-passing 
libraries without recompiling any of the extension modules. The
only tricky part was building different versions of Python (which
required among other things, the MPI_Init() problem mentioned
above).

Hope this helps.

Cheers,

Dave



.