Chris -

When we look at ABI stability for Open MPI releases, we look only at the MPI 
and SHMEM interfaces, not the internal interfaces used by Open MPI internally. is an internal library, and we do not guarantee ABI stability 
across minor releases.  In 3.0.3, there was a backwards incompatible change in, which is why the shared library version numbers were increased 
in a way that prevented loading a new version of when the 
application was linked against an earlier version of the library.

In practice, this should not be a problem.  The wrapper compilers (and our 
instructions for linking when not using the wrapper compilers) only link 
against (or a set of libraries if using Fortran), as 
contains the public interface. has a dependency on, 
so the loader will load the version of that matches the version 
of Open MPI used to build  However, if someone explicitly links 
against, you end up where we are today.

There’s probably a bug in HDF5’s mechanism for linking against Open MPI, since 
it pulled in a dependency on  However, there may be some things 
we can do in the future to better handle this scenario.  Unfortunately, most of 
the Open MPI developers (myself included) are at the SC’18 conference this 
week, so it will take us some time to investigate further.


> On Nov 14, 2018, at 5:20 AM, Christopher Samuel <> wrote:
> Hi folks,
> Just resub'd after a long time to ask a question about binary/backwards 
> compatibility.
> We got bitten when upgrading from 3.0.0 to 3.0.3 which we assumed would be 
> binary compatible and so (after some testing to confirm it was) replaced our 
> existing 3.0.0 install with the 3.0.3 one (because we're using hierarchical 
> namespaces in Lmod it meant we avoided needed to recompile everything we'd 
> already built over the last 12 months with 3.0.0).
> However, once we'd done that we heard from a user that their code would no 
> longer run because it couldn't find and saw that instead 
> 3.0.3 had
> Initially we thought this was some odd build system problem, but then on 
> digging further we realised that they were linking against libraries that in 
> turn were built against OpenMPI (HDF5) and that those had embedded the 
> names.
> Of course our testing hadn't found that because we weren't linking against 
> anything like those for our MPI tests. :-(
> But I was really surprised to see that these version numbers were changing, I 
> thought the idea was to keep things backwardly compatible within these series?
> Now fortunately our reason for doing the forced upgrade (we found our 3.0.0 
> didn't work with our upgrade to Slurm 18.08.3) was us missing one combination 
> out of our testing whilst fault-finding and having gotten it going we've been 
> able to drop back to the original 3.0.0 & fixed it for them.
> But is this something that you folks have come across before?
> All the best,
> Chris
> -- 
>  Christopher Samuel     OzGrav Senior Data Science Support
>  ARC Centre of Excellence for Gravitational Wave Discovery
> _______________________________________________
> devel mailing list

devel mailing list

Reply via email to