Le mercredi 15 octobre 2008 à 16:13 -0400, Jeff Squyres a écrit : > Static libraries are definitely a Good Thing in some scenarios. We > have a few features in this arena, which we consider separately: > > - building libmpi (and friends) as .a instead of .so > - slurping all the plugins into libmpi (and friends) instead of > creating them as standalone DLLs > - disabling dlopen altogether > > When someone says "building static", they usually mean enabling all 3 > of those options. This can be really helpful for running massive > scale MPI jobs, for example. It also helps decrease complexity by > decreasing the number of run-time variables for problematic or > production environments. In short, we recognize that everyone has > different requirements, so we try to enable everyone to do what they > need. > > So yes, we believe that building statically is a Good Thing. But by > default, we disable all of those options and build everything > dynamically because it's the most flexible and results in the smallest > user MPI executables. That is the "usual" case that users care > about. Make sense? Totaly and you explained perfectly everything.
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 ? Thx, Sylvestre -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]