I have moved the hyprestruct matrix definition from mat directory to the dm/da directory. This should resolve the problem for you.
Barry On Jan 2, 2010, at 11:28 PM, Jed Brown wrote: > 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