Open MPI logo

Open MPI User's Mailing List Archives

  |   Home   |   Support   |   FAQ   |   all Open MPI User's mailing list

Subject: Re: [OMPI users] ABI stabilization/versioning
From: Jed Brown (jed_at_[hidden])
Date: 2010-01-25 16:15:52

On Mon, 25 Jan 2010 15:10:12 -0500, Jeff Squyres <jsquyres_at_[hidden]> wrote:
> Indeed. Our wrapper compilers currently explicitly list all 3
> libraries (-lmpi -lopen-rte -lopen-pal) because we don't know if those
> libraries will be static or shared at link time.

I am suggesting that it is unavoidable for the person doing the linking
to be explicit about whether they want static or dynamic libs when they
invoke mpicc. Consider the pkg-config model where you might write

  gcc -static -o my-app main.o `pkg-config --libs --static openmpi fftw3`

  gcc -o my-app main.o `pkg-config --libs openmpi fftw3`

In MPI world,

  gcc -static -o my-app main.o `mpicc -showme:link-static` `pkg-config --libs --static fftw3`

  gcc -o my-app main.o `mpicc -showme:link` `pkg-config --libs fftw3`

seems tolerable. The trick (as you point out) is to get the option
processed when the wrapper is being invoked as the compiler instead of
just for the -showme options. Possible options are defining an
OMPI_STATIC environment variable or inspecting argv for --link:static
(or some such). This is one many the reasons why wrappers are a
horrible solution, especially when they are expected to be used in
nontrivial cases.

Ideally, the adopted plan could be done in some coordination with MPICH2
(which lacks a -showme:link analogue) so that it is not so hard to write
portable build systems.

> > On the cited bug report, I just wanted to note that collapsing
> > libopen-rte and libopen-pal (even only in production builds) has the
> > undesirable effect that their ABI cannot change without incrementing
> > the soname of libmpi (i.e. user binaries are coupled just as tightly
> > to these libraries as when they were separate but linked explicitly,
> > so this offers no benefit at all).
> Indeed -- this is exactly the reason we ended up leaving libopen-* .so
> versions at 0:0:0.

But not versioning those libs isn't much of a solution either since it
becomes possible to get an ABI mismatch at runtime (consider someone who
uses them independently, or if they are packaged separately as in a
distribution so that it becomes possible to update these out from
underneath libmpi).

> There's an additional variable -- we had considered collapsing all 3
> libraries into libmpi for production builds,

My point was that this is no solution at all since you have to bump the
soname any time you change libopen-*. So even users who NEVER call into
libopen-* have to relink any time something happens there, despite their
interface not changing. And that is exactly the situation if the
wrappers continue to overlink AND libopen-* became versioned, so at
least by keeping them separate, you give users the option of not
overlinking (albeit manually) and the option of using libopen-* without

> Yuck.

It's 2010 and we still don't have a standard way to represent link
dependencies (pkg-config might be the closest thing, but it's bad if you
have multiple versions of the same library, and the granularity is
wrong, e.g. if you want to link some exotic lib statically and the
common ones dynamically).