Thanks for the hints. > You have some possible workarounds: > > - We recommended to the PyMPI author a while ago that he add his own > dlopen() of libmpi before calling MPI_INIT, but specifically using > RTLD_GLOBAL, so that the library is opened in the global process space
> (not a private space in the process). Then libmpi's (and friends) > symbols will be available to its plugins. If you're unhappy with the > non-portability of dlopen, try lt_dlopen_advise() -- it's a portable > version that is linked inside Open MPI. This is the solution we go with our "modified python" approach. We do not exactly dlopen libmpi but simply link the Python binary against it, which has the same effect. > - Another option is to configure/compile Open MPI with "--disable- > dlopen" or "--enable-static --disable-shared" configure options. > Either of these options will cause Open MPI to slurp all of its > plugins up into libmpi (etc) and not dynamically open them at run- > time, thereby avoiding the problem of Python opening libmpi in a > private scope. This sounds good, I gotta try this. > - Get Python to give you the possibility of opening dependent > libraries in the global scope. This may be somewhat controversial; > there are good reasons to open plugins in private scopes. But I have > to imagine that OMPI is not the only python extension out there that > wants to open plugins of its own; other such projects should be > running into similar issues. That would involve patching Python in some nifty places which would probably lead to less Platform independence, so no option yet. --- Michael Meinel German Aerospace Center Center for Computer Applications in Aerospace Science and Engineering
