On Wed, 24 Dec 2014, Matthew Knepley wrote: > On Wed, Dec 24, 2014 at 3:48 PM, Jed Brown <[email protected]> wrote: > > > Barry Smith <[email protected]> writes: > > > > >> On Dec 24, 2014, at 12:26 PM, Jed Brown <[email protected]> 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
