On Jul 11, 2018, at 3:56 AM, Alastair McKinstry 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 ?
SHORT VERSION
=
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
so.
MORE DETAIL
===
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
deep!).
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
functions/globals.
- 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).
Thoughts?
--
Jeff Squyres
jsquy...@cisco.com
___
ompi-packagers mailing list
ompi-packagers@lists.open-mpi.org
