On Thu, 4 Feb 2010 09:49:42 -0300, Lisandro Dalc?n <dalcinl at gmail.com> wrote: > I was going to propose exactly the same. However, I bet that some > (older?) platforms (not using ELF?) will not work like in Linux, and > then a -lpetsc front-end will not work as you expect because of > broken/missing support por shared lib dependencies.
I wouldn't know, but this is the purpose of shared libraries. > As I commented long ago, convenience for end-users (single include, > single library) is clear benefit, even in the case of static linking. Satish pointed out that this can cause problems, such as duplicate global variables, if the user also uses a third-party library directly. That is, if a huge libpetsc.a includes such dependencies (e.g. --whole-archive -lparmetis -lhdf5) then the user is required to *not* link those dependencies themselves if PETSc happened to be configured with them. With static libs, there is no way to avoid explicitly linking recursive dependencies, and people who work with static libs expect this. It is only with shared libraries that you get to only link the interface libs (and in fact, *should not* link recursive dependencies). Jed
