On Dec 11, 2007, at 9:08 AM, Lisandro Dalcin wrote:
>> (for a nicely-formatted refresher of the issues, check out https://svn.open-mpi.org/trac/ompi/wiki/Linkers)
> Sorry for the late response...
> I've finally 'solved' this issue by using RTLD_GLOBAL for loading the
> Python extension module that actually calls MPI_Init(). However, I'm
> not completelly sure if my hackery is completelly portable.
> Looking briefly at the end of the link to the wiki page, you say that
> if the explicit linking to libmpi on componets is removed, then
> dlopen() has to be explicitelly called.
> Well, this would be a mayor headhace for me, because portability
> issues. Please note that I've developed mpi4py on a rather old 32 bits
> linux box, but it works in many different plataforms and OS's. I do
> really do not have the time of testing and figure out how to
> appropriatelly call dlopen() in platforms/OS's that I even do not have
Yes, this is problematic; dlopen is fun on all the various OS's...
FWIW: we use the Libtool DL library for this kind of portability; OMPI
itself doesn't have all the logic for the different OS loaders.
> Anyway, perhaps OpenMPI could provide an extension: a function call,
> let say 'ompi_load_dso()' or something like that, that can be called
> before MPI_Init() for setting-up the monster. What to you think about
> this? Would it be hard for you?
(after much thinking...) Perhaps a better solution would be an MCA
parameter: if the logical "mca_do_dlopen_hackery" (or whatever) MCA
parameter is found to be true during the very beginning of MPI_INIT
(down in the depths of opal_init(), actually), then we will
lt_dlopen[_advise]("<path>/libmpi"). For completeness, we'll do the
corresponding dlclose in opal_finalize(). I need to think about this
a bit more and run it by Brian Barrett... he's quite good at finding
holes in these kinds of complex scenarios. :-)
This should hypothetically allow you to do a simple putenv() before
calling MPI_INIT and then the Right magic should occur.