The plugin idea is a good one, and probably your best option (e.g.,
have an MPI plugin and a non-MPI plugin). FWIW, plugins are the
foundation of Open MPI -- we determine which functionality is
available at run-time by opening plugins and querying them. Plugins
generally do one of the following:
1. open and load successfully, and when queried, report that they can
be used in the current environment (e.g., the OpenFabrics network
plugin reports "yes, I can be used" if it finds OpenFabrics network
devices on the host)
2. open and load successfully, but then report that they cannot be
used when queried
3. open successfully, but do not load (e.g., shared library that they
depend on cannot be found)
4. do not open successfully (e.g., were compiled for a different
architecture)
Case 1 is the only scenario where you can use that functionality. In
case 2, you can just close the plugin and unload it. In cases 3 and
4, they didn't even load into your process space to begin with, so you
can ignore them.
In Open MPI, we call all case 1 plugins "available". For each type of
plugin, we take all the available plugins and apply some kind of
"selection" logic to determine which we want to use. For some things,
we only want the "best" 1 of N available plugins; for other things, we
want to use all N of N available plugins (e.g., network transports for
MPI).
If you go the plugin route, you do end up divorcing the main
executable from the back-end functionality, so your executable doesn't
have dependencies on the back-end libraries (such as libmpi.so), which
is nice. I would strongly recommend using the libltdl library from
GNU Libtool for doing all the dlopen() / dlsym() / dlclose()
functionality. Libltdl is a portable mechanism for doing all this
kind of stuff and works across a variety of POSIX-like operating
systems.
On Sep 25, 2008, at 7:57 AM, jody wrote:
I don't think there is an Open-MPI based solution for this.
I would probably to the following:
- place all functions using MPI calls into a separate module and
create a shared-object dynamic library (so file).
- create another .so file which contains the non-MPI equivalents of
those functions
At runtime, determine whether MPI is present. If yes, dynamically
load the
MPI-functions .so, and otherwise load the Non-MPI-functions .so
However beware that you will have problems if you will use this
application on a system
whose Open-MPI has a different version than the one you compiled your
application with.
Jody
On Thu, Sep 25, 2008 at 1:26 PM, Ali Copey <alicopey...@yahoo.com>
wrote:
Hello,
We have created a piece of software that is designed to work under
a variety
of conditions, one of which is using MPI.
This application will preferably us a single executable and then
load the
mpi communications interface as a library at runtime, however
adding this
functionality by compiling using the mpi compile wrappers creates an
executable that will not run on a system without mpi installed.
Is it possible to have the main executable not dependent upon the
presence
of mpi but still able to load the mpi dependent library if mpi is
required,
and how would this be achieved?
Thank you,
Alex
_______________________________________________
users mailing list
us...@open-mpi.org
http://www.open-mpi.org/mailman/listinfo.cgi/users
_______________________________________________
users mailing list
us...@open-mpi.org
http://www.open-mpi.org/mailman/listinfo.cgi/users
--
Jeff Squyres
Cisco Systems
