Open MPI logo

Open MPI Development Mailing List Archives

  |   Home   |   Support   |   FAQ   |   all Development mailing list

Subject: Re: [OMPI devel] RFC: libopen-rte --> libompi-rte
From: Jeff Squyres (jsquyres_at_[hidden])
Date: 2008-11-06 20:24:08


FWIW: Terry told me in IM that he hates this RFC as well (more details
coming later).

On Nov 6, 2008, at 2:58 PM, Ralf Wildenhues wrote:

>>> Hmm, OpenMPI seems not to use versioning for its shared libraries.
>>
>> That was on the to-do list for this release, but it just didn't
>> happen.
>> :-\
>
> Oh well. When you start doing it, please coordinate with
> distributors;
> it's not likely, but some of them may have actually packaged OpenMPI
> with versioning, including (one then hopes!) adjusting versions as
> needed between releases. You might want to start out with numbers
> upward of that then.

Will do; thanks for the tip.

>> MPI API is compatible across releases; it hasn't changed. We have
>> never
>> [yet] claimed ABI compatible across releases -- we may still do this
>> someday.
>
> FWIW, this task looks quite a bit easier to me than, say, defining an
> ABI valid for several MPI implementations.

Yes; our biggest issue is the fact that gcc complains when the size of
structs change, even though those structs are never exposed to MPI
applications. Specifically:

1. MPI_Comm is defined as "typedef struct ompi_communicator_t *MPI_Comm"
2. If we change the size of the ompi_communicator_t struct between two
different versions of libmpi, gcc warns when user MPI applications are
linked against a new libmpi

Everything seems to work since MPI_Comm is only ever used as an opaque
handle by the MPI application. But we haven't looked deeply [yet] to
see if there are more hidden dragons than this, and if not, if there
is a way to suppress the warning.

-- 
Jeff Squyres
Cisco Systems