<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Thu, Dec 25, 2014 at 12:35 PM, Satish Balay <span dir="ltr"><<a href="mailto:balay@mcs.anl.gov" target="_blank">balay@mcs.anl.gov</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On Wed, 24 Dec 2014, Matthew Knepley wrote:<br>
<br>
> On Wed, Dec 24, 2014 at 3:48 PM, Jed Brown <<a href="mailto:jed@jedbrown.org">jed@jedbrown.org</a>> wrote:<br>
><br>
> > Barry Smith <<a href="mailto:bsmith@mcs.anl.gov">bsmith@mcs.anl.gov</a>> writes:<br>
> ><br>
> > >> On Dec 24, 2014, at 12:26 PM, Jed Brown <<a href="mailto:jed@jedbrown.org">jed@jedbrown.org</a>> wrote:<br>
> > >><br>
> > >> In this case, it might be more reliable to compare "cc --version".<br>
> > ><br>
> > >   Presumably this is trivial with the gnumake stuff?<br>
> ><br>
> > It's easy to run it and compare before proceeding with the build.<br>
> ><br>
> > >   And  the mythical petsc-config could do any number of sanity checks<br>
> > each time it is run.<br>
> ><br>
> > It might be desirable to have a<br>
> ><br>
> >   petsc-config verify CC=cc CFLAGS='-m32 -mcmodel=large'<br>
> > CXXFLAGS=-std=c++11 ...<br>
> ><br>
> > that would check whether the given compiler configuration is<br>
> > binary-compatible with the way PETSc was built.  It should be reasonably<br>
> > fast, but could actually run the compiler.<br>
> ><br>
><br>
> I of course want these runtime checks. They are the biggest piece missing<br>
> from the<br>
> package model.<br>
<br>
</span>Hm - most package models [fedora ecosystem or perhaps debian and<br>
similar] enforce uniform options [compilers, compiler options etc..]<br>
for all packages in that ecosystem - so such issues don't come up.<br>
<br>
And even if petsc were packaged as a 'module' in such a system [say<br>
cray-petsc] - these issues usually don't come up. I think when<br>
compiler modules get switched - the petsc libraries (via modules) also<br>
get switched to the ones compatible with the current compiler..<br></blockquote><div><br></div><div>This is exactly the point of view I hate because it does not describe our experience.</div><div>People want the compilers they want, and the packages. The best thing to do is</div><div>check everything at build time so that incompatibilities are caught early.</div><div><br></div><div>   Matt</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
This issue usually come up when user builds PETSc from source with one<br>
enviornment - but attempts to use it from a different one..<br>
<span class="HOEnZb"><font color="#888888"><br>
Satish<br>
</font></span></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature">What most experimenters take for granted before they begin their experiments is infinitely more interesting than any results to which their experiments lead.<br>-- Norbert Wiener</div>
</div></div>