Hi all.. I have to contact you again about the issues related to dlopen()ing libmpi with RTLD_LOCAL, as many dynamic languages (Python in my case) do.
So far, I've been able to manage the issues (despite the "do nothing" policy from Open MPI devs, which I understand) in a more or less portable manner by taking advantage of the availability of libtool ltdl symbols in the Open MPI libraries (specifically, in libopen-pal). For reference, all this hackery is here: http://code.google.com/p/mpi4py/source/browse/trunk/src/compat/openmpi.h However, I noticed that in current trunk (v1.4, IIUC) things have changed and libtool symbols are not externally available. Again, I understand the reason and acknowledge that such change is a really good thing. However, this change has broken all my hackery for dlopen()ing libmpi before the call to MPI_Init(). Is there any chance that libopen-pal could provide some properly prefixed (let say, using "opal_" as a prefix) wrapper calls to a small subset of the libtool ltdl API? The following set of wrapper calls would is the minimum required to properly load libmpi in a portable manner and cleanup resources (let me abuse of my previous suggestion and add the opal_ prefix): opal_lt_dlinit() opal_lt_dlexit() opal_lt_dladvise_init(a) opal_lt_dladvise_destroy(a) opal_lt_dladvise_global(a) opal_lt_dladvise_ext(a) opal_lt_dlopenadvise(n,a) opal_lt_dlclose(h) Any chance this request could be considered? I would really like to have this before any Open MPI tarball get released without libtool symbols exposed... -- 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
