[petsc-dev] Mat/DM dependency

[Jed Brown]

On Sat, 02 Jan 2010 21:39:13 -0700, Jed Brown <jed at 59A2.org> wrote:
> This is standard behavior, and I believe it's a good thing

To elaborate on this, suppose libA provides the symbol AFunc() which has
some weird dependency.  Suppose libB does not reference AFunc() and some
application appC depends on libB.  Since AFunc() is unreachable when we
link appC, a permissive linker will let the silent dependencies slip by
unresolved.  Now we update libB (without changing it's ABI) so that
AFunc() is referenced.  Since appC has not changed, we should be able to
just update libB and appC should not need to be touched.  But since the
linker let the dependencies for the formerly unreachable AFunc() slip by
when we linked appC, we now have a broken executable.  A stricter linker
would have forced us to resolve the dependencies up front so that we
can't silently end up with this broken executable.

Also, I'm missing something else if the present isn't very brittle with
static libs due to the link order.  That is, -lpetscdm -lpetscmat could
leave DA symbols in libpetscmat.a unresolved, requiring something like
-lpetscdm -lpetscmat -lpetscdm.  (This only applies if the application
didn't reference these symbols, which any reasonable application
probably needs to do in this case, explaining why it hasn't caused a
problem yet.)

Note that we already have MatSchurComplement in libpetscksp.

Jed