Open MPI logo

Open MPI Development Mailing List Archives

  |   Home   |   Support   |   FAQ   |   all Development mailing list

Subject: Re: [OMPI devel] RFC: ABI break between 1.4 and 1.5 / .so versioning
From: Ralf Wildenhues (Ralf.Wildenhues_at_[hidden])
Date: 2010-02-18 01:53:43

* Jeff Squyres wrote on Wed, Feb 17, 2010 at 11:51:42PM CET:
> On Feb 17, 2010, at 3:05 PM, Ralf Wildenhues wrote:
> > > The issue is that if the user has to specify -static to their linker,
> > > they *also* have to specify --ompi:static, or Bad Things will happen.
> > > Or, if they don't specify -static but *only* specify --ompi:static,
> > > Bad Things will happen. In short: it seems like adding yet another
> > > wrapper-compiler-specific flag to the MPI ecosystem will cause
> > > confusion, fear, and possibly the death of some cats.
> >
> > Do you care for omitting -lopen-pal and -lorte only for capable Linux
> > systems? With new-enough binutils, you should be able to use
> > -Wl,--as-needed -Wl,--no-as-needed around these two libs.
> Mmmm. Good point. But I don't think it helps us on Solaris or OS X, does it? (maybe it does on OS X?) Or do all linkers have some kind of option like this? (this *might* be a way out, but I would probably need to be convinced :-) )

No, I think only binutils ld (and gold) have this. Sorry.

> > I'm not entirely sure I understand your argumentation for why libmpi
> > from 1.5.x has to be binary incompatible, but I haven't fully thought
> > through this yet.
> The context for this issue is so long that much was left out of my mail. Here's this particular issue in a nutshell:
> - Open MPI v1.4.1 has libmpi at 0:1:0 and libopen-rte and libopen-pal both at 0:0:0.
> - Open MPI v1.4.1 links MPI apps against -lmpi -lopen-rte -lopen-pal.
> - If we start .so versioning properly in v1.5, it's likely that libopen-rte and libopen-pal will both be 1:0:0.
> --> Note that these are both internal libraries; there are no symbols in these libraries that are used in the MPI applications.
> - Open MPI v1.5 libmpi *could* be 1:0:1.
> - Hence, an a.out created for OMPI v1.4.1 would work fine with v1.5 libmpi.
> - But that a.out would not work with v1.5 libopen-rte and libopen-pal.

You could probably create fake empty libopen-rte and libopen-pal stub
libraries with 0:0:0 purely for the sake of allowing such an a.out to
still work (on systems with versioned sonames[1]). Since this doesn't
actually use any of the APIs from those libraries, there is no problem
here, and your 1.5 libmpi will pull in the 1:0:0 versions of the other
two libraries.

I understand if you decide not to go such ways, and in that case, I
agree that bumping libmpi to 1:0:0 won't cause much extra pain.


[1] This includes many but probably not all systems with shared
libraries. E.g., I think AIX without runtimelinking (-Wl,-brtl)
would have a problem.