dolfin team mailing list archive

["Matthew Knepley" <knepley@xxxxxxxxx>]

>  This is the behavior I observed, although it was more than a year ago
>  that I put a line in my makefile to determine if mpicxx existed in the
>  same path, and if not, try to use the mpicc (provided by PCC_LINKER) as
>  a C++ compiler.  I generally use openmpi, but often build PETSc
>  with-clanguage=C since I don't use the C++ interface (I'm playing with
>  sieve now so this has changed).  Then PCC_LINKER would give me a C
>  compiler (mpicc) and I would look for a C++ compiler at the same path
>  (since the code I was compiling was C++).  This worked great for me, but
>  it broke for some people who had PETSc install mpich2.  The problem was
>  that mpicc was actually a C++ compiler and there was no mpicxx at that
>  path.  It would have been a PETSc configured with-clanguage=C++.  In
>  trying to reproduce this with a recent PETSc (2.3.3-p6 and petsc-dev) it
>  looks like mpich2 produces just mpicc (which is not a C++ compiler) when
>  configured with-clanguage=C and correctly produces mpicxx when
>  with-clanguage=C++.  This is entirely sane behavior.  I'm not sure why
>  Osman is seeing the former behavior even with a recent PETSc.

Yes, if C++ is not turned on in PETSc, we will not generate an mpicxx when
installing MPICH2. For the C compiler, we take whatever is specified
using --with-cc
or the one we find by default if nothing is specified. You can see which one we
found using mpicc --show.

  Matt

-- 
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