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
