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 ? 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 https://rfd.newmexicoconsortium.org/mailman/listinfo/ompi-packagers
