Re: [OMPI devel] Dynamic languages, dlopen() issues, and symbol visibility of libtool ltdl API in current trunk

On Mon, Sep 21, 2009 at 9:45 AM, Jeff Squyres wrote: > Ick; I appreciate Lisandro's quandry, but don't quite know what to do. > I'm just asking the library "libopen-pal.so" exposing ltdl calls wrapped with an "opal_" prefix. This way, the original ltdl calls hare hidden (no

Re: [OMPI devel] Dynamic languages, dlopen() issues, and symbol visibility of libtool ltdl API in current trunk

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

Re: [OMPI devel] Dynamic languages, dlopen() issues, and symbol visibility of libtool ltdl API in current trunk

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

Re: [OMPI devel] Dynamic languages, dlopen() issues, and symbol visibility of libtool ltdl API in current trunk

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