On Jan 25, 2010, at 12:55 PM, Jed Brown wrote:
> > The short version is that the possibility of static linking really
> > fouls up the scheme, and we haven't figured out a good way around this
> > yet. :-(
> So pkg-config addresses this with it's Libs.private field and an
> explicit command-line argument when you want static libs, e.g.
> $ pkg-config --libs libavcodec
> $ pkg-config --libs --static libavcodec
> -pthread -lavcodec -lz -lbz2 -lfaac -lfaad -lmp3lame -lopencore-amrnb -lopencore-amrwb -ltheoraenc -ltheoradec -lvorbisenc -lvorbis -logg -lx264 -lm -lxvidcore -ldl -lasound -lavutil
> There is no way to simultaneously (a) prevent overlinking shared libs
> and (b) correctly link static libs without an explicit statement from
> the user about whether to link *your library* statically or dynamically.
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. If they're shared, then listing -lmpi should be sufficient because its implicit dependencies should be sufficient to pull in the other two (and therefore libopen-rte and libopen-pal can have their own, independent .so version numbers. yay!). But if they're static, then libmpi has no implicit dependencies, and you *have* to list all clauses (-lmpi -lopen-rte -lopen-pal).
We did not want our wrapper compilers to get in the business of:
- attempting to divine whether the link will be static or dynamic (e.g., could be as "simple" [read: not really] as parsing argv, but could be as difficult as reading compiler config files).
- figuring out shared library filenames (e.g., .so, .dylib, .dll, ...etc.).
> Unfortunately, pkgconfig doesn't work well with multiple builds of a
> package, and doesn't know how to link some libs statically and some
> 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.
There's an additional variable -- we had considered collapsing all 3 libraries into libmpi for production builds, but the problem here is that multiple external projects have starting using libopen-rte and libopen-pal independently of libmpi. Hence, we can't just make those libraries disappear. :-\ The developers of those external projects don't want a big monolithic library to link against, particularly when they have nothing to do with MPI.