SHORT VERSION: We broke ABI from the 1.4 series to the v1.5 series. I propose changing all the libtool .so version numbers as shown below to enforce that break. Can someone sanity check this?
--- VERSION (revision 23242)
+++ VERSION (working copy)
@@ -79,12 +79,12 @@
# Version numbers are described in the Libtool current:revision:age
# "Common" components install standalone libraries that are run-time
# linked by one or more components. So they need to be versioned as
@@ -92,5 +92,5 @@
# components-don't-affect-the-build-system abstraction.
libopen_rte.so now wholly includes libopen_pal.so, and libmpi.so wholly includes libopen_rte.so (and therefore also libopen_pa.so). This was done for complex reasons -- the quick explanation is that is sucks because it makes us break ABI right now, but it puts us in a better position for ABI compatibility in the future. I wish that we had figured this out back at v1.3.2 when we introduced ABI compatibility, but we didn't -- so here we are. Cope.
To enforce this ABI break, I propose setting the libtool version numbers of all of our shared libraries to 1:0:0. This means that apps linked against v1.5 libmpi.so will *NOT* be able to use libmpi.so from the v1.3 or v1.4 series. They will have to relink (at a minimum).
Resetting *all* the library numbers to 1:0:0 is probably overkill (e.g., there's probably little gained by resetting the common libraries to 1:0:0), but it seems like an "ok" thing to do -- reset all the numbers across the board for minimum confusion.
Can someone sanity check my rationale here? I'm not tied to this scheme; it just seems simple and, while probably being a bit overly broad, makes the change easy to describe and consistent.
For corporate legal information go to: