[Pkg-openmpi-maintainers] Bug#502232: Bug#502232: libopenmpi-dev: No static libraries in the package

[Jeff Squyres]

On Oct 15, 2008, at 4:26 PM, Sylvestre Ledru wrote:

> We just need a precision on a specific point.
> When we use the option --enable-static, a dynamic library is no longer
> available (libmca_common_sm.so.0.0.0). The Makefile.am says that:
> # 2. libmca_common_sm.la is a static library.  In this case, it will
> # be rolled up into the top-level libmpi.la.  It will also be rolled
> # into each component, but then the component will also be rolled up
> # into the upper-level libmpi.la.
>
> but we don't really understand why this becomes mandatory when  
> compiling
> in static.
> Does it make sense to keep this dynamic library (despite the
> enable-static option) and to produce the static too or will it cause
> bugs ?


Sorry -- I forgot to address this point.

Short version: this is mainly a reminder/note to us developers, and  
should not be a problem for you.

Longer version:

The way we have our Makefile.am's setup, this library is linked  
against a few different OMPI plugins.  That is, both libmpi and each  
of the plugins have:

   ... -lmca_common_sm ...

in their link step.

When libmca_common_sm.so.0.0.0 is built dynamically, it's all good  
because each of those plugins simply has a reference to the dynamic  
libmca_common_sm.so.0.0.0 library, and the run-time linker figures it  
all out nicely.  Specifically: the run-time linker will only import  
the libmca_common_sm.so.0.0.0 library *once*.

When building statically, then each plugin (and libmpi) will contain a  
full copy of whatever symbols it pulls out of libmca_common_sm.a.  So  
there could be a possibility of duplicated symbols.  E.g., say symbol  
"foo" is in libmca_common_sm.a and is used by all the plugins that use  
this library and libmpi.  Then a full copy of the foo symbol  
definition will be in each.  Then when libmpi slurps in all the  
plugins via a link step, will we get duplicate "foo" symbol errors?   
Thankfully, no.  We have not yet found a linker that doesn't just  
"figure it out" and know that the duplicate foo's are actually the  
*same* foo, and therefore only include *one* foo in the resulting  
executable.

Make sense?

-- 
Jeff Squyres
Cisco Systems