Open MPI logo

Open MPI User's Mailing List Archives

  |   Home   |   Support   |   FAQ   |   all Open MPI User's mailing list

Subject: Re: [OMPI users] Compiling for portability to non-mpi systems.
From: Jeff Squyres (jsquyres_at_[hidden])
Date: 2008-09-25 08:19:50


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 <alicopey158_at_[hidden]>
> 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
>> users_at_[hidden]
>> http://www.open-mpi.org/mailman/listinfo.cgi/users
>>
> _______________________________________________
> users mailing list
> users_at_[hidden]
> http://www.open-mpi.org/mailman/listinfo.cgi/users

-- 
Jeff Squyres
Cisco Systems