On Thu, Dec 25, 2014 at 12:35 PM, Satish Balay <[email protected]> wrote:

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 is exactly the point of view I hate because it does not describe our experience. People want the compilers they want, and the packages. The best thing to do is check everything at build time so that incompatibilities are caught early. Matt

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

Satish

-- What most experimenters take for granted before they begin their experiments is infinitely more interesting than any results to which their experiments lead. -- Norbert Wiener