I have switched back to using the mpich-master-v3.0.4-106-g3adb59c.tar.gz I messed up and put that change into a commit when I shouldn’t have. (I still miss the nice bk gui that showed cleanly each change you were committing).
But it is extremely worrisome that we need to use PARTICULAR versions of MPI implementations to get clean compilers?!?!?! 1) Isn’t this fundamentally wrong? 1.5) Do we want to be in the business of saying, “if you use compiler XX version YY then you need to use MPICH implementation version ZZ, otherwise it won’t work? 2) Shouldn’t we be portable to all the various MPI implementations that are released at various times? 3) Do we need a configure test to properly handle the “broken” MPI implementations? It seems to me that we need to have configure either A) declare certain MPI implementations as broken and tell the user to change implementations or B) use conditional compiles so PETSc builds cleanly even with these “broken” MPI implementations. How are we going to fix this? remember not everyone uses —download-mpich Barry On Jan 4, 2014, at 9:49 PM, Jed Brown <[email protected]> wrote: > Satish Balay <[email protected]> writes: >> We were previously using v3.0.4 [with some bug fixes for some issues that >> came up in petsc testing]. >> >> http://ftp.mcs.anl.gov/pub/petsc/tmp/mpich-master-v3.0.4-106-g3adb59c.tar.gz > > Barry, what was the idea here? > > https://bitbucket.org/petsc/petsc/commits/7904a3320b8a1f45505a06da988fac624ac5e24c > > It's certainly unrelated to the rest of the commit. Shall we just > revert that part? > > > And how is it that the MPICH release has a memory bug for 8 months > during which time they haven't put out a new patch release (3.0.5)? > > http://git.mpich.org/mpich.git/commit/3adb59cb83a4f675ba990062c62396d1a23483cf
