On 12/13/07, Jeff Squyres <jsquyres_at_[hidden]> wrote:
> On Dec 12, 2007, at 7:47 PM, Lisandro Dalcin wrote:
> Specifically: it would probably require some significant hackery in
> the OMPI build process to put in a #define that indicates whether OMPI
> is being built statically or not. But the AM/LT process shields this
> information from the build process by design (part of the issue is
> that AM/LT allows both static and shared libraries to be built
> We'd then have to introduce some global symbol that
> could be queried that is outside of the MPI interface. Neither of
> these things are attractive. :-(
You are right, a globlal symbols is not attractive at all just for this.
> > AFAIK, Python does not. It uses specific, private code for this,
> > handling the loading of extension modules according to the OS's and
> > their idiosyncracies. However, Python enable users to change the flags
> > used for dlopen'ing your extension modules; the tricky part is to get
> > the correct values RTLD_GLOBAL in a portable way.
> That's somewhat surprising -- there's no public interfaces for modules
> to portably load sub-modules? Bummer.
Perhaps I was not clear enough. There are many public ways of
importing modules in Python. Modules can came mainly from two sources:
pure Python code, or C compiled code. In the later case (called
extension modules), they are normally a shared object
(.so,.dylib,.dll) exporting only a simbol: 'void
init<modulename>(void)', this functions bootstraps the initialization
of the extension module. What is somewhat hidden is the actual way
Python loads this shared object and calls the init function. I believe
the reason for this is related to de gory details of dlopen()ing in
different OS's/archs combination.
Anyway, Python enables you to temporarily change the flags to be used
in dlopen() calls, what is not (currently) so easy is to get the value
of RTLD_GLOBAL in a portable way.
Jeff, in short: I believe I solved (with the help of Brian) the issue
in the context of Python and the platforms we have access to. So, from
our side, things are working.
However, I believe this issue is going to cause trouble to any other
guy trying to load shared objects using MPI. This makes me think that
Open MPI should be in charge or solving this, but I understand the
situation is complex and all us are usually out of time. I'll try to
re-read all the stuff to better understand the beast.
Centro Internacional de Métodos Computacionales en Ingeniería (CIMEC)
Instituto de Desarrollo Tecnológico para la Industria Química (INTEC)
Consejo Nacional de Investigaciones Científicas y Técnicas (CONICET)
PTLC - Güemes 3450, (3000) Santa Fe, Argentina