On Wed, 24 Dec 2014, Matthew Knepley wrote:

> On Wed, Dec 24, 2014 at 3:48 PM, Jed Brown <jed@jedbrown.org> wrote:
>
> > Barry Smith <bsmith@mcs.anl.gov> writes:
> >
> > >> On Dec 24, 2014, at 12:26 PM, Jed Brown <jed@jedbrown.org> wrote:
> > >>
> > >> In this case, it might be more reliable to compare "cc --version".
> > >
> > >   Presumably this is trivial with the gnumake stuff?
> >
> > It's easy to run it and compare before proceeding with the build.
> >
> > >   And  the mythical petsc-config could do any number of sanity checks
> > each time it is run.
> >
> > It might be desirable to have a
> >
> >   petsc-config verify CC=cc CFLAGS='-m32 -mcmodel=large'
> > CXXFLAGS=-std=c++11 ...
> >
> > that would check whether the given compiler configuration is
> > binary-compatible with the way PETSc was built.  It should be reasonably
> > fast, but could actually run the compiler.
> >
>
> I of course want these runtime checks. They are the biggest piece missing
> from the
> package model.

Hm - most package models [fedora ecosystem or perhaps debian and
similar] enforce uniform options [compilers, compiler options etc..]
for all packages in that ecosystem - so such issues don't come up.

And even if petsc were packaged as a 'module' in such a system [say
cray-petsc] - these issues usually don't come up. I think when
compiler modules get switched - the petsc libraries (via modules) also
get switched to the ones compatible with the current compiler..

This issue usually come up when user builds PETSc from source with one
enviornment - but attempts to use it from a different one..

Satish