On Jan 25, 2010, at 7:11 AM, Dave Love wrote: > What's the status of (stabilizing and?) versioning libraries? If I > recall correctly, it was supposed to be defined as fixed for some > release period as of 1.3.something.
Correct. We started with 1.3.2 or 1.3.3, IIRC...? I'd have to go back and check to be sure. To be clear, however, we are only versioning the MPI libraries (as you noted, libmpi went to 0.0.1). That is, the hidden sub-libraries (libopen-rte and libopen-pal) are still NOT versioned for complex, icky reasons (see https://svn.open-mpi.org/trac/ompi/ticket/2092 for more details). The short version is that the possibility of static linking really fouls up the scheme, and we haven't figured out a good way around this yet. :-( To be absolutely crystal clear: OMPI's MPI shared libraries now have .so versioning enabled, but you still can't install two copies of Open MPI into the same $prefix (without overriding a bunch of other directory names, that is, like $pkglibdir, etc.). This is because Open MPI has a bunch of files that are not named in relation to OMPI's version number (e.g., $includedir/mpi.h, $mandir/man3/*, $pkgdir/*, libopen-rte.so, etc.). That is, the lack of .so versioning in libopen-rte and libopen-pal are only two of (unfortunately) many reasons that you can't install 2 different versions of Open MPI into the same $prefix. Does that make sense? > I assumed that the libraries would then be versioned (at least for ELF > -- I don't know about other formats) and we could remove a major source > of grief from dynamically linking against the wrong thing, and I think > Jeff said that would happen. Right -- we're using the Libtool shared library versioning scheme. > However, the current sources don't seem to > be trying to set libtool version info, though I'm not sure what > determines them producing .so.0.0.1 instead of .0.0.0 in other binaries > I have. The top-level VERSION file has text fields that set what the version numbers will be for each of the so libraries. These numbers get pasted in to various Makefile's in the build process; hence, the LT .so versioning info is included down at the level where each .so library is created (by Libtool). Check out our wiki page about the shared library version numbering: https://svn.open-mpi.org/trac/ompi/wiki/ReleaseProcedures. > This doesn't seem to have been addressed in the Debian or > Fedora packaging, either > > Is that just an oversight or something dropped, so it could be fixed > (modulo historical mess) if someone did the work? It isn't covered > under http://www.open-mpi.org/software/ompi/versions/ or as far as I can > tell in the FAQ, and seems important (like plenty of other things, I'm > sure!), given how much of a problem it's been for users and admins doing > updates. Good point -- I'll take a to-do to add some text about the shared library versioning scheme in the FAQ and the /versions/ page. Probably not today, but I should be able to get to it this week. Do the links and text I provided above give you enough information / rationale? -- Jeff Squyres jsquy...@cisco.com
