So I started down this road a couple months ago. I was using the
lt_dlopen() and friends in the OPAL CRS self module. The visibility
changes broke that functionality. The one solution that I started
implementing was precisely what you suggested, wrapping a subset the
libtool calls and prefixing them with opal_*. The email thread is below:
http://www.open-mpi.org/community/lists/devel/2009/07/6531.php
The problem that I hit was that libtool's build system did not play
well with the visibility symbols. This caused dlopen to be disabled
incorrectly. The libtool folks have a patch and, I believe, they are
planning on incorporating in the next release. The email thread is
below:
http://thread.gmane.org/gmane.comp.gnu.libtool.patches/9446
So we would (others can speak up if not) certainly consider such a
wrapper, but I think we need to wait for the next libtool release
(unless there is other magic we can do) before it would be usable.
Do others have any other ideas on how we might get around this in the
mean time?
-- Josh
On Sep 16, 2009, at 5:59 PM, Lisandro Dalcin wrote:
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
_______________________________________________
devel mailing list
de...@open-mpi.org
http://www.open-mpi.org/mailman/listinfo.cgi/devel
