On Mon, 25 Jan 2010 15:10:12 -0500, Jeff Squyres <jsquy...@cisco.com> 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 libmpi. > 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). Jed
