dolfin team mailing list archive

["Åsmund Ødegård" <aasmund@xxxxxxxxx>]

On Sun, Mar 16, 2008 at 10:44 PM, Matthew Knepley <knepley@xxxxxxxxx> wrote:
> >  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.
>

This make kind of sense, of course. But it also makes it a bit hard,
as Petsc tend to be quite picky about compilers. Dolfin is C++, so
some mpicxx is needed when Dolfin and Petsc are linked together. Maybe
the best solution is to skip the wrappers altogether, just extract
what we need from mpicc -show, and build the correct commands.

Probably have to sleep on this :)

Åsmund