On Jul 11, 2018, at 3:56 AM, Alastair McKinstry <mckins...@debian.org> wrote:
> Also, I'd like to revisit the Symbol versioning feature 
> (https://github.com/open-mpi/ompi/issues/1956).

(Splitting this into its own thread)

> This was closed due to lack of followup on my part at the time (sorry about 
> that). AFAIK the problem is making my gcc patch work on other compilers; is 
> this the case, and if it was reopened what compilers should be targetted ?


We had a lengthy discussion about this today on the weekly OMPI engineering 
webex, and we generally agree with you.  We'll try hard not to increase the .so 
version number for v4.0.0, but we're not going to promise to do this until we 
do a full ABI-backwards-compatibilty analysis.

But heads up that we will almost certainly break ABI compatibility (and 
therefore increase the .so version number) in v5.0.0 (sometime in 2019 -- 
probably mid- to late- year, but we haven't put a date on it yet).  So if you 
want to revisit symbol versioning/etc., it's right about the right time to do 


We're nearly out of time for 4.0.0 -- we're branching for that tomorrow (i.e., 
feature complete, but not necessarily bug free).  But I think the door is open 
for a symbol versioning feature for future releases.

I re-read the following to re-familiarize myself with this proposal:

- https://github.com/open-mpi/ompi/issues/1906
- https://github.com/open-mpi/ompi/pull/1955
- https://github.com/open-mpi/ompi/issues/1956

Re-reading this all at once helped page back in all the issues, and I think I 
understand it better than I did back then.

The real issue -- as you stated multiple times, but I don't think I really 
fully grokked at the time -- is that you just want libmpi.so.X (and OSHMEM), 
and you don't want X to change so that you don't have to recompile a bazillion 
other packages (especially since Debian's MPI dependencies can get to be 5 

Per Geoff's/Howard's replies, I now see how this ties in to your request to not 
increment the SO major version number.

A few additional points to add into the conversation:

1. In Open MPI v4.0.0, we are finally not including some deleted MPI-1 
functions in mpi.h/mpif.h/mpi/mpi_f08 by default any more (i.e., they were 
actually deleted 5+ years ago, but we've still been carrying+building them).  A 
packager can configure with --enable-mpi1-compatibility if they want those 
functions in the devel headers (the symbols will still be available in all 
cases -- see below).

2. The .so versions (i.e., Libtool c:r:a versions) are determined by the 
*default* build build options.  For example, a v4.0.0 default build will 
actually delete some MPI functions that were there in v3.1.x.  We talked about 
making the "a" value be dependent upon configure options... but that seems 
problematic / full of dragons.

--> We're not 100% what the Right Thing is to do here yet.

3. Depending on how you packaged Open MPI v3.1.x, you'll likely also want to 
--enable-mpi-cxx in v4.0.0 to keep building the C++ MPI bindings.  These 
bindings are a separate library than the C bindings, meaning that when you 
enable this option, you get a new library when you install.

4. Per our discussion today, this is what we decided on as a roadmap for v4.0.x 
and v5.0.x.  We think that this is congruent with your request, but please 
chime in with your thoughts:

4a. In v4.0.0:
    - By default, we'll disable the prototypes for various MPI-1 functions that 
were deleted from the MPI standard years ago.
    - Packagers can --enable-mpi1-compat to restore these deleted MPI-1 
functions/globals in mpi.h/mpif.h/mpi+mpi_f08 modules.  Meaning: this option 
mainly affects *compiling* applications that use the deleted MPI-1 
    - Regardless of whether --enable-mpi1-compat is used, the symbols for these 
functions and globals will still be in libmpi.  Assuming the rest of the ABI 
analysis works out well and v4.0.0 is ABI compatible with v3.0.x, then you can 
have a app/library compiled against OMPI v3.0.x that will ABI link successfully 
with v4.0.0, even if they're using these deleted MPI-1 functions/globals.

4b. In v5.0.0:

- The C++ bindings will no longer be available.
  Meaning: this library will no longer be generated.
- The deleted MPI-1 functions will no longer be available.
  Meaning: these functions/globals will disappear both from 
mpi.h/mpif.h/mpi+mpi_f08 and from all the corresponding libraries.

BOTTOM LINE: this is an announcement of our intent to actually delete the C++ 
bindings and the deleted MPI-1 functions in Open MPI v5.0.0.

As mentioned above, there is no strict timeline for v5.0.0 yet -- it'll be in 
2019 sometime (I'd estimate mid-year at the earliest, but that's a SWAG).


Jeff Squyres

ompi-packagers mailing list

Reply via email to