Python/SWIG: Namespace collisions in multiple modules.

[Konrad Hinsen]

Jakob Schiotz <schiotz1 at yahoo.com> writes:

> I previously had two (slightly) different functions with the same name
> in two modules, that cause a coredump when I tried to use both modules
> in the same Python script.  I changed the name of the function in one
> module, but this may happen again with functions (in particular
> library functions) where I cannot change the name.

This may be unavoidable on some systems. It all depends on how the OS
treats symbols in shared libraries. It might take the view that the
main executable plus all shared libraries used by it are logically one
big program, in which symbols must be unique. Or it might decide that
each shared library constitutes a different name space and only
explicitly exported symbols are global to the program. Or it might let
the main executable decide how to proceed. There seems to be no
portable solution for using two functions with the same name.

There is a discussion of this problem in the Extending & Embedding
manual: http://www.python.org/doc/current/ext/using-cobjects.html


> 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

In my experience, the only portable solution is to have all modules
that directly call MPI routines linked statically with the modified
Python executable. This is the solution I have adopted for the MPI
module in ScientificPython
(ftp://dirac.cnrs-orleans.fr/pub/ScientificPython/ScientificPython-2.1.1.tar.gz). To make life easier for MPI application programs, ScientificPython
provides a complete C API to its functions which includes more or less
direct MPI calls as well as higher-level functions. This means that
although ScientificPython requires a special Python executable (which
is produced automatically during installation), application modules
can use MPI from shared libraries without any problems; they needn't
even be linked with the MPI library.
-- 
-------------------------------------------------------------------------------
Konrad Hinsen                            | E-Mail: hinsen at cnrs-orleans.fr
Centre de Biophysique Moleculaire (CNRS) | Tel.: +33-2.38.25.55.69
Rue Charles Sadron                       | Fax:  +33-2.38.63.15.17
45071 Orleans Cedex 2                    | Deutsch/Esperanto/English/
France                                   | Nederlands/Francais
-------------------------------------------------------------------------------