On 12/13/07, Jeff Squyres <jsquy...@cisco.com> 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 > simultaneously).
I see. > 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. Regards, -- Lisandro Dalcín --------------- 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 Tel/Fax: +54-(0)342-451.1594
