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 > -lavcodec > $ 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.). Yuck. > Unfortunately, pkgconfig doesn't work well with multiple builds of a > package, and doesn't know how to link some libs statically and some > dynamically. > > 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. Yuck. -- Jeff Squyres jsquy...@cisco.com
