On Dec 12, 2007, at 7:47 PM, Lisandro Dalcin wrote:
You should, yes.
OK, but now I realize that I cannot simply call libtool dlopen()
inconditionally, as libmpi.so could not exist in a static lib build.
Right. Or it could be libmpi.dylib (OS X). I don't know if other
extensions exist out there.
However, in this case, it would be easy enough to just try a few named
extensions (libmpi.<foo>) -- they'll either all fail or one of them
will succeed. But you would still need to tell if you're linked
against libmpi.a or not -- dlopen'ing a shared library version when
you already have a static version resident can cause problems (per the
chart on the wiki).
Actually, regardless of who does the dlopen -- you or me -- we need to
know this info (whether the linked-against libmpi was shared or
static). Hmm. I can't think of a good way to do this off the top of
my head.
After a little more thought, I think only the application can know
this -- the application's build system can know whether it is linking
against libmpi.a or libmpi.so and set some #define (or whatever) to
know whether it needs to dlopen libmpi or not. :-\
Specifically: it would probably require some significant hackery in
the OMPI build process to put in a #define that indicates whether OMPI
is being built statically or not. But the AM/LT process shields this
information from the build process by design (part of the issue is
that AM/LT allows both static and shared libraries to be built
simultaneously). We'd then have to introduce some global symbol that
could be queried that is outside of the MPI interface. Neither of
these things are attractive. :-(
Also, see my later post: doesn't perl/python have some kind of
portable dlopen anyway? They're opening your module...?
Sorry -- it looks like the post I was referring to got stuck in my
outbox and didn't get sent until earlier this morning.
AFAIK, Python does not. It uses specific, private code for this,
handling the loading of extension modules according to the OS's and
their idiosyncracies. However, Python enable users to change the flags
used for dlopen'ing your extension modules; the tricky part is to get
the correct values RTLD_GLOBAL in a portable way.
That's somewhat surprising -- there's no public interfaces for modules
to portably load sub-modules? Bummer.
Is there any another way of setting a MCA parameter?
See http://www.open-mpi.org/faq/?category=tuning#setting-mca-params.
OK, it seems there isn't a programatic way. Anyway, putenv() should
not be a souce of portability problems.
No, we have no API for setting MCA params other than altering the
environment. Also, most MCA params are read during MPI_INIT and not
re-checked later during the run (it would be a bad idea, for example,
to check MCA param values during the critical performance path).
--
Jeff Squyres
Cisco Systems
