Jeff, Tim, We had request by a Gary from Sandia about providing static libs, which we seemed to have turned off a while ago. Looking into the matter Sylvestre and Gary found that we can in fact enable this easily (as your FAQ suggested) but at the expense of libmca_common.so.
Your docs have this: > # This library is linked against various MCA components because all > # shared-memory based components (e.g., mpool, ptl, etc.) need to > # share some common code and data. There's two cases: > # > # 1. libmca_common_sm.la is a shared library. By linking that shared > # library to all components that need it, the OS linker will > # automatically load it into the process as necessary, and there will > # only be one copy (i.e., all the components will share *one* copy of > # the code and data). > # > # 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. Linkers universally know how to > # "figure this out" so that we end up with only one copy of the code > # and data. > # > # Note that building this common component statically and linking > # against other dynamic components is *not* supported! But it seems that we can't quite wrap our head around the implications. So to make it simpler: -- would recommended for or against providing static as well as shared libraries? -- do we risk anything here that could upset our users? -- should we able to build everything in one pass (ie one configure call, one make, one make install -- which is the current setting that seems to work) Gary made a valid point, and for certain cluster deployments I can see how have static builds may make life easier (no lib-syncing etc pp, even though of course this is the very thing that .deb packages make relatively easy). Any advice you could provide would be appreciated. Cheers from Chicago, Dirk -- Three out of two people have difficulties with fractions. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]