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: Jeff Squyres (jsquyres_at_[hidden])
Date: 2010-02-17 14:19:25


Brian and I talked higher bandwidth to figure this out.

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.

The alternate proposal is to have one-big-honkin' libmpi that slurps in all of libopen-rte and libopen-pal. We'll still install libopen-rte and libopen-pal because the tools (like orterun and friends) will need them. But MPI apps will only -lmpi, regardless of whether they are static or shared. There will never be a need to -lopen-rte and -lopen-pal for MPI apps.

Analogous things will happen for ORTE: libopen-rte will slurp in libopen-pal. And ORTE apps will only -lopen-rte. Birds will sing. Children will play. The world will be content.

--> NOTE: The ABI break will still occur between 1.4 and 1.5 because we'll be .so versioning libopen-pal and libopen-rte. The only issue Brian was concerned about was the modification of the wrapper compilers.

If we do this, is there anyone who will still want the old 3-library behavior? Specifically:

a) the libraries are not slurped into each other, and
b) the MPI wrapper compilers still list all 3 libraries / ORTE wrapper compilers still list 2 libs

If so, we can add a --with-wrappers-linking-all-libs configure switch (or something with a better name) to support the old behavior, but I'd argue that it should not be the default.

On Feb 17, 2010, at 1:31 PM, Barrett, Brian W wrote:

> On Feb 17, 2010, at 11:23 AM, Jeff Squyres wrote:
> > Here's my proposal on how to change the wrapper compilers to understand the difference between static and dynamic linking:
> >
> > *** FIRST: give the wrapper the ability to link one library or all libraries
> > - wrapper data text files grow a new option: libs_private (a la pkg-config(1) files)
> > - wrapper data text files list -l<top_lib> in libs, and everything else in libs_private. For example, for mpicc:
> > libs=-lmpi
> > libs_private=-lopen-rte -lopen-pal
> >
> > *** NEXT: give the wrappers the ability to switch between just ${libs} or ${libs}+${libs_private}. Pseudocode:
> > - wrapper always adds ${libs} to the argv
> > - wrapper examines each argv[x]:
> > --ompi:shared) found_in_argv=1 ;;
> > --ompi:static) add ${libs_private} ; found_in_argv=1 ;;
> > - if (!found_in_argv)
> > - if default set via configure, add ${libs_private} (SEE BELOW)
>
> This is horrible! Users want to be able to specify -Bstatic or -static or whatever and have the right things happen. I have a better idea - since there's basically no set of users which use OMPI's libopal and some other libopal (and indeed, that's near impossible do to the horrible API exposed by opal (data type sizes changing based on configure arguments, for example), let's give up and just have libmpi.{so,a} and completely avoid this whole rat hole of a problem?
>
> There's simply no way your solution is workable for most users. They'll just end up wondering why when they do -Bstatic (or whatever the option is on their compiler) they get missing symbol link errors.
>
> Brian
>
> _______________________________________________
> devel mailing list
> devel_at_[hidden]
> http://www.open-mpi.org/mailman/listinfo.cgi/devel
>

-- 
Jeff Squyres
jsquyres_at_[hidden]
For corporate legal information go to:
http://www.cisco.com/web/about/doing_business/legal/cri/