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
> de...@open-mpi.org
> http://www.open-mpi.org/mailman/listinfo.cgi/devel
>
--
Jeff Squyres
jsquy...@cisco.com
For corporate legal information go to:
http://www.cisco.com/web/about/doing_business/legal/cri/
