As a workaround, Lisandro could just pre-seed the cache variables of the respective configure tests that come out wrong.
./configure lt_cv_dlopen_self=yes lt_cv_dlopen_self_static=yes HTH. Cheers, Ralf * Jeff Squyres wrote on Mon, Sep 21, 2009 at 02:45:28PM CEST: > Ick; I appreciate Lisandro's quandry, but don't quite know what to do. > > How about keeping libltdl fvisibility=hidden inside mpi4py? > > > On Sep 17, 2009, at 11:16 AM, Josh Hursey wrote: > > >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...
